AI and Gender-Based Violence Case Management

Last updated: 2026-08-15

Gender-based violence case management is among the highest-risk applications for AI in humanitarian work. AI should not assess risk, determine eligibility, or interact directly with survivors. The defensible uses are administrative: reducing the documentation burden on caseworkers so that more of their time is spent with the people they serve.

Where AI can and cannot support gender-based violence case management, and why this is among the highest-risk applications in humanitarian work.

AI and Gender-Based Violence Case Management

This is the application where the general humanitarian AI arguments stop being abstract. The data describes people whose safety may depend on it never being seen by the wrong person. The decisions carry consequences that cannot be reversed by an appeal. And the survivors involved have, by definition, already experienced harm from someone with power over them.

The correct starting position is scepticism, and a willingness to conclude that the answer is no.

What AI should not do here

It should not assess risk. Risk assessment in GBV work determines whether someone is moved to a safe location, whether a case is escalated, and how urgently. These judgements depend on context a system cannot see: what the survivor did not say, what the caseworker observed, what is known about the local situation. A model trained on historical case records learns the patterns of past decisions, including their failures, and applies them with false consistency. The risk tiering criteria would place this at the highest consequence tier, where automated decision-making is not appropriate.

It should not determine eligibility for services. This is a decision about a person, and it belongs to a named caseworker with an appeal route.

It should not interact directly with survivors. A survivor disclosing violence to an automated system receives no protection response, may believe they have reported something when they have not, and has disclosed sensitive information into a channel with unclear retention. The general case is set out in AI chatbots for crisis-affected people; here the argument is stronger, not weaker.

It should not aggregate case data into a central analytical store by default. GBV case data is among the most tightly access-controlled information any humanitarian organisation holds, and for sound reasons. A data pipeline built for analytics can quietly defeat controls that took years to establish.

Where it can legitimately help

The defensible applications share a property: they act on the caseworker's own workload, not on the survivor or the decision.

Reducing documentation burden. Caseworkers spend a substantial share of their time writing up notes rather than with the people they serve. A system that drafts a case note from a caseworker's own dictated summary, for that caseworker to correct and approve, returns time to service delivery. The survivor is not in the loop, the output is reviewed before it is saved, and nothing is decided.

Translation support for caseworkers. In multilingual operations, interpretation is often a bottleneck and sometimes a confidentiality risk when interpreters are drawn from the same small community. Machine translation used by a trained caseworker, with a human interpreter still available and with the limits understood, can widen access. Language coverage must be tested in the dialects actually spoken, per AI governance in the Arab region.

Referral pathway lookup. Which service is open, where, accepting which cases, with what documentation. This is stable procedural information of the kind that is safe to retrieve, and keeping it current is a real operational problem.

Data quality within existing boundaries. Identifying duplicate or inconsistent records inside a system that already holds the data, without moving it, so that a survivor is not asked to repeat their account because two records exist.

Conditions that must hold

If an organisation proceeds with even the narrow uses above, four conditions are not negotiable.

Inference location is decided, not inherited. Case content must not be sent to a third-party service under default terms. For most organisations this means local or private deployment, which is examined in LLM security in public institutions.

Existing access controls survive the system. If the AI component can read across cases that a caseworker could not, the controls have been defeated regardless of intent.

The caseworker approves every output before it is saved. Draft, never record.

Survivor consent covers this specific use. Consent obtained for case management does not extend to processing by an external system, and consent given under duress or dependency is not meaningful consent. This is the hardest condition to satisfy honestly.

The test to apply

Before building, answer the 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 where the system stops being confident.

For GBV case management, the honest answer to the first question is usually severe and sometimes irreversible. That does not rule out every application, but it does mean the burden of proof sits with the proposal, and that "the technology now allows it" is not an argument. Where the answer is uncertain, the correct decision is to leave the process as it is and spend the effort on staffing instead.

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