How is the social sector building and evaluating AI tools?
Key takeaways
Drawn from 571 AI use cases on the Social Good AI Hub and interviews with seven organisations.
- Chatbots and other conversational tools are the most common use case, at about 34% of the total, and within that category nine in ten run on a large language model, a text-based type of foundation model.
- Across all use cases, nearly seven in ten build on a foundation model of some kind, text and others. Organisations typically layer on their own data, knowledge, or additional models to adapt them for context-specific needs.
- Of the use cases that disclose licensing status, 41% are open source. There is meaningful variability across sectors: 73% of use cases in the climate sector were open source, compared to 21% in livelihoods. Staff bandwidth, funding incentives and data licences keep many tools closed.
- Six in ten use cases publish evidence on how their tools are used, but only 17% report a measured change in outcomes such as learning or health.
- Shared benchmarks, usable government data and models for less-served languages would help many organisations at once, but no single organisation can build them alone.
Introduction
To understand how the social sector is building and evaluating AI tools, we analyzed 571 use cases documented on the Social Good AI Hub and in-depth interviews with seven organisations that have deployed AI tools.
The social sector is investing significant time, money and attention in AI, and organisations are building tools to tackle problems in education, health, livelihoods, climate and beyond. Behind each tool is a series of choices that shape what gets built and how useful it can become.
We follow these choices across four stages, from deciding what to build and how to build it, to evaluating if these tools are delivering the outcomes envisioned.
What to build
The kinds of tools organisations build and the platforms they run on
How much to customize
How much organisations rely on models others built, and what they add themselves
What to release openly
Whether organisations publish their code or models, and what holds them back
Whether the tool works
What evidence organisations collect and publish, from model performance to outcomes for people
What gets built: chatbots are the most common tool
Whether or not they use a chatbot, the jobs these conversational tools do vary widely. The most common applications are diagnosis and screening, tutoring, and forecasting, which were the primary function of the conversational tool in 15 to 17% of use cases each.
What AI tools do varies widely
Share of the 571 use cases carrying each of the main functional tags
screening
learning
prediction
early warning
analytics
matching
knowledge retrieval
generation
assistive technology
research
transcription
entitlements access
These chatbots are often built on WhatsApp. Three organizations we spoke to highlight that this was because users are already familiar with the platform and nothing new needs to be installed. However, using an existing platform also means being subject to its pricing, limits and available features. As messaging costs have risen, one organisation we spoke to is raising funds to move to its own app.
The same is true of the AI models powering these chatbots. Among chatbot tools that name their model, three in four use one of the three frontier models: GPT, Gemini, or Claude. This creates a shared dependency: a change by one of these providers, such as their pricing, model capabilities, or local language support, can affect many tools at once.
These dependencies also have a financial dimension. Organisations pay for every message and model call each time someone uses a chatbot. Naturally, these costs grow as a tool reaches more people and continue after grants and donated credits run out. Tracking these costs early, and planning for changes by platforms and model providers, is becoming critical to keeping an AI tool running.
Plan for costs after launch
Digital tools have traditionally been expensive to build but cheap to run, so reaching more people cost little extra. AI tools change this: every message and model call costs money, so running costs rise with each new user. Grants and donated credits often cover building and piloting a tool, but less often the cost of running it in steady use. AI companies and cloud providers offer credits and nonprofit discounts, and some funders invest in scaling proven tools. But credits run out, running costs can go unfunded once a grant ends, and handing a tool to a government or other long-term owner can take years. Funders can budget for running costs that grow with use for tools that have shown they work, and for the work of bringing those costs down, such as replacing parts of a tool with smaller, cheaper models. They can also support the work needed to prepare tools for handover, such as building modular systems and creating documentation.
How much to build in-house: start from existing models, add what is context-specific
Across use cases, four underlying AI approaches12 are most common:
- Foundation models: large general-purpose models pretrained on vast amounts of text, images, audio or other data, which others can use for many tasks without additional training. Examples include GPT, Gemini, Claude, Llama and the speech model Whisper.
- Bespoke deep learning: neural networks trained, or fine-tuned from an existing model, on data for one specific task, such as spotting crop disease in photos, mapping settlements from satellite imagery or transcribing a low-resource language.
- Classical machine learning and statistical methods: established techniques such as regression, decision trees and clustering, applied to structured data like survey responses or administrative records to predict outcomes or group cases.
- Symbolic, optimisation, and decision methods: approaches built on explicit rules, objectives and constraints, or that learn the best action through trial and feedback, such as eligibility rules, route and resource-allocation optimisation, knowledge graphs and adaptive experiments.
69% of use cases build on top of a foundation model. It is the most common approach in seven of the nine sectors represented on the Hub (all but climate and agriculture), and appears in more than 80% of use cases in education, livelihoods, governance, justice and social protection.
How often each AI approach is used
Share of the 571 use cases using each approach
models
and statistical methods
learning
and decision methods
Our interviews help explain why. Organisations rarely build AI from scratch. Instead, they start with a model that already exists and build parts that are specific to their problem, such as adding custom instructions, integrating organisational knowledge and documents, or sometimes adding in a smaller model trained or adapted for a particular task. A foundation model might understand a user’s question and draft a reply, while the organisation’s own data and models check the answer against guidelines, adapt advice to local conditions, or decide what a learner sees next.
The balance between off-the-shelf and in-house components varies by use case. The examples below show how organisations make those choices.
Some types of problems still require bespoke models: images, sensor and satellite data
Bespoke deep learning is most common in humanitarian response (50%), climate (46%) and agriculture (45%), where tools often work with satellite images, sensor readings or photos. Foundation models are common in these sectors too, appearing in 63% of humanitarian use cases, 59% in agriculture and 44% in climate.
Humanitarian, climate and agriculture work lean on bespoke deep learning
Share of each sector’s use cases using models trained for one specific task, such as reading satellite imagery or spotting crop disease. The three highest are highlighted.
The more local knowledge a tool needs, the more organisations build custom parts
The same principle applies when a tool needs knowledge that is highly specific to a place. Organizations we spoke to built more in-house when the knowledge a tool needed was specific to a place, such as local crop or pest variants or state-specific natural disaster data.
Where shared infrastructure could help
Some of the components organisations build in-house, such as making government data usable, local-language resources and model benchmarks, are also needed by others building AI tools in the same field. Building this infrastructure once and sharing it broadly could limit the need for each organization to start on the same problems from scratch and would help direct limited resources towards tool improvements.
Government data commons
For organisations working with government stakeholders in the Global South, the data they need is often already collected, but held in formats that are hard to build on. CivicDataLab spends much of its effort building pipelines that make datasets from different departments work together. A common data standard, adopted by the departments that hold the data, could let that work be done once. Where records exist but are not shared, such as some records of disaster losses, data-sharing agreements could open them up.
Language models for less-served languages
EIDU named better models for local languages as shared infrastructure it would like to see built. Rising Academies would like to offer Rori in local languages, but current models handle African languages poorly. Without better models, organisations build their own language resources: Edufarmers’ tech partner built a database of local dialects. Foundation models have since improved enough to make that specific database unnecessary, but progress is uneven, and organisations working in less-served languages still lack the models they need.
Independent benchmarks for AI in each field
A benchmark is a shared test with agreed correct answers. Without one, each organisation builds its own tests or goes without. A shared benchmark could let every organisation in a field compare tools before choosing one and check its own models. To be useful, it has to test a specific task, such as reading policy documents or marking a student’s maths answer. Organisations we spoke to found that general rankings of AI models told them little about how a model would perform in their own tool.
Help unlock government data
Efforts to standardise and share government data have a long and mixed record, from uncoordinated mobile health pilots3 to disaster loss data that countries report unevenly.4 Newer platforms, such as the UN System Data Commons launched in September 2026, bring published national statistics together, but data held by sub-national departments remains harder to reach. Where standards already exist, such as UNDRR’s DELTA Resilience for disaster loss data, funders can pay for the long work of getting departments to adopt them, which often costs more than designing the standard itself. For sensitive data, they can help governments set safeguards that make sharing less risky when a tool’s value justifies it.
Invest in language models for less-served languages
Today’s AI models handle many less-served languages poorly, so organisations build their own language resources or limit their tools to widely spoken languages. Groups such as Masakhane, AI4Bharat, Karya and Bhashini have built datasets and models for African and Indian languages, and in September 2026, 60 organisations committed to making AI usable for 3.4 billion people who speak underrepresented languages. Even so, most of these languages still lack enough high-quality data, and existing datasets often miss the accents, dialects and switching between languages that real users bring. Funders can back the collection of language data as well as models, prioritising data that reflects how people actually speak and the sectors where tools will be used, such as health and education, and pay for evaluations of how well models perform in them.
Invest in shared knowledge for AI tools
Most AI tools that give advice rely on documents their builders collect and check themselves, so the same guidelines are gathered, cleaned and updated many times over, at varying quality. A shared context layer built from official sources, such as national curricula, health guidelines and benefits eligibility rules, would give every tool the same trusted starting point and let each answer be traced back to a named source. Learning Commons and Oak National Academy already do this for school curricula in the United States and England, and IDinsight is building similar layers for education in several low- and middle-income countries. Funders can back these layers in other sectors and countries, ideally maintained by the bodies that already publish the guidance, so they stay current once initial funding ends.
What to release openly: openness varies by sector
Of the 315 use cases on the Hub that disclose whether their code or models are open, 41% are open source.5 Looking within sectors, there is significant variation: the rate of open-sourcing ranges from 73% for climate-focused tools to 21% for livelihoods-focused tools. Four sectors stand out on openness: climate, humanitarian response, governance, and agriculture.
Share of use cases that are open source, by sector
Among the 315 use cases that disclose their status. The four sectors where most tools are open are highlighted.
Why some sectors are more open than others
Types of data leveraged and research norms in climate
Much of the AI used in climate is built by teams training their own models, often on public satellite imagery that carries little privacy risk. Many of these tools are built and used by researchers who expect to see the data and methods behind a result. The two climate organisations we spoke to treated openness as part of their work from the start: Climate TRACE publishes its data and methods, and Climate Policy Radar, which is funded by philanthropy, aims to put its work in the public domain so others can check and improve it. Together, these factors may help explain why climate is among the most open sectors.
Government customers
Openness can also be an advantage when governments are the customers. CivicDataLab, a private company, publishes all its code openly. Its government partners want to own the tools they use and avoid being tied to one supplier, so for CivicDataLab open code is an advantage rather than a cost. Noora Health’s government partners ask for two things: open code, which their own staff can run without a lengthy tender, and open-weight models, which reduce dependence on models built abroad and keep data in the country. This may also partly explain why governance is among the more open sectors, though governments also buy plenty of proprietary software.
What keeps organisations from opening up their tools
That said, across the Hub, the majority of tools (that disclose their status) are not open source. The organisations we spoke to pointed to a few reasons:
Funding incentives
Releasing a platform can give away what sets the organisation apart, or weaken the case for further funding: once a good-enough open version exists, funders may stop paying for a tool’s development or maintenance.
Data licences
Some models rely on data bought under licence, which can restrict releasing it even when the code itself could be shared.
Bandwidth
Putting code online is not the same as making it usable. Releasing a tool properly means documenting it and its limitations, separating it from internal systems, removing personal information, and maintaining it after release. Rising Academies, for example, has to check any dataset it releases for students’ names and locations, which students sometimes type alongside their answers. Organisations with small teams often cannot spare the time, and two that we spoke to said that code released without this work is of little use to anyone else.
Pay for the work of releasing code and models openly
Releasing a tool’s code or models openly takes time: documenting them, separating them from internal systems and personal information, maintaining them, and responding to the questions and requests that come once others start using them. Funders have backed open source for years. The Principles for Digital Development, endorsed by more than 300 organisations including donors, ask organisations to share and reuse their work, and the Digital Public Goods Alliance’s standard requires documentation good enough for someone unfamiliar with a tool to launch and run it themselves. Our interviews suggest the gap lies in paying for that work. Funders can set aside dedicated budget for releasing tools openly, covering documentation, release and support for early users, and keep funding a tool’s development after it is released.
Whether the tool works: evidence narrows from use to outcomes
Each use case entry on the Hub documents the evidence around the solution, when available. We categorize the evidence in line with the four-level framework from the GenAI Evaluation Playbook. Each level asks a different question:
- Model: Does the AI perform as intended, for example by giving accurate and safe answers?
- Product: Do people use the tool as intended and keep coming back?
- User: Does using the tool change what people think, feel, know, or do?
- Impact: Do people with access to the tool see better development outcomes, such as in learning, health or income?
The levels build on each other: a tool that does not perform as intended is unlikely to retain users, and outcomes are unlikely to improve if users drop off or the tool does not change what they know or do.
Six in ten use cases publish evidence on how their tools are used, and about two in five on whether the AI performs as intended or changes what users do. 45% publish something at the impact level, but most of that falls short of a measured change in outcomes.
Share of use cases publishing evidence at each level
Read from the bottom up: each level rests on the one below
4. Impact
Does it improve outcomes for the people it serves?
3. User
Does it change what users think, know or do?
2. Product
Do people use the tool and keep coming back?
1. Model
Does the AI perform as intended?
What organisations said about model evaluation
Most organisations we spoke to test their models more than their public evidence shows. They run test sets built from their own data, check results with officials on the ground, or have human reviewers mark a sample. Few publish these results.
One challenge is knowing what a result means. Without a benchmark, a shared test with agreed correct answers, a score is hard to judge: one organisation has an internal accuracy figure of around 90% but has held off publishing it, unsure whether 90% is good enough. Others pointed to the time it takes to prepare results for release, and the need to remove personal information first.
Evidence of impact on people is still thin. Only 17% of use cases report a measured change in an outcome, such as higher test scores or fewer hospital readmissions, and just 6% measure that change against a comparison group. The rest of the impact evidence takes several forms: around 6% report counts of outcomes without a before-and-after comparison, such as the number of people who found jobs; around 5% report cost or time savings; about 13% make claims about impact without reporting figures; and another 5% describe how impact is or will be measured.
Our interviews point to five reasons why organisations often have evidence on use but not yet on outcomes that are independently evaluated:
The field is still early
Many organisations are adding AI to programmes that already exist and are still working out what to measure. Reach (how many people a tool serves) and use (how often and in what ways they use it) are therefore often the first things they can report. Where outcomes have been measured, the results usually reflect the whole programme. Edufarmers tried to isolate what its farming chatbot added, but its early sample of users was too small. More rigorous evaluation is on the way. Rising Academies already has independent evidence for Rori from an Oxford/J-PAL randomised trial in Ghana, which found a 0.36 standard deviation gain in maths learning, and is now running a larger randomised controlled trial with the University of Ghana. Noora Health is running two trials, one focused on its AI with partners at Stanford University, and Edufarmers plans to try again as more farmers use its chatbot.
A tool that keeps changing
Test datasets are slow and expensive to build, and can become outdated as the tool, underlying data or users’ needs change. Climate Policy Radar relies on continuous feedback from domain experts instead. Trials face the same problem. With its AI trial, Noora Health is navigating the balance between the rigorous evidence demanded of its services and the rapid pace of product development and innovation.
A poor result carries risk
Some organisations noted that a poor public result can carry real consequences. One agreed to an independent evaluation only once its own measurement gave it confidence that the tool worked. This follows the order set out at the start of this section: first check that the AI works and that people use it, then test whether outcomes improve. It also means evidence on impact takes longer to appear.
Evaluation competes for resources
One organisation pointed out that money spent on a randomised trial is money not spent on the product. Cost usually came up alongside staff time, competing priorities and the pull to keep improving the tool. In one case, evaluation was possible only because a neighbouring programme in the same area had money for data collection.
Not every tool is suited to an impact evaluation
Some tools inform decisions made by other people, such as a policy database used by researchers or emissions data used by governments, so there is no clear group of users to compare with non-users. Other tools operate at a scale too small for a randomised trial, and open-ended assistants are hard to tie to a single measurable outcome. These tools can still show whether they are used and trusted, and whether they shape decisions. Climate Policy Radar tracks who uses its database and gathers feedback from the people it trains, such as members of parliament, and CivicDataLab compares its recommendations with how funding is actually allocated.
Signal what evidence matters at each stage
The four levels in this report give funders and grantees a shared language for what to ask for, and the GenAI Evaluation Playbook suggests asking for model evaluation results before requiring an impact evaluation. Early tools can show how the model performs and how people use it, and then whether it changes what they know or do. For tools in stable use at scale that are suitable for an impact evaluation, agreeing early in a multi-year grant when this will happen gives organisations time to plan and budget for it. Tools that do not suit an impact evaluation can still track the outcomes they aim to improve, even if those changes cannot be attributed to the tool alone.
Fund independent benchmarks for common tasks
General AI benchmarks exist, but few test the tasks social-sector tools commonly perform, such as reading climate policy documents or spotting crop disease in local photos, or measure what matters in a sector, such as whether a lesson plan follows good teaching practice. Funders can help identify the most common tasks within and across sectors and build shared benchmarks for them, using real ground-truth data with agreed correct answers. These would also help organizations publish their model results: once many tools are scored on the same test, the field can see what a good score looks like. Benchmarks work best when built by someone whose own tools will not be scored against them. In education, Fab AI already publishes benchmarks that test whether leading AI models can pass teacher exams, solve early-grade visual maths problems and support teaching in local languages. The language commitment launched in September 2026 includes work on benchmarks for underrepresented languages, and in health, the AI Commons for Global Health, launched in July 2026, is building shared tools to test whether AI works in a given context.
Back new, cheaper ways to evaluate
Many tools are not ready or appropriate for a full randomized controlled trial, and others cannot yet afford one. AI tools have one advantage: because they run digitally, changes can be tested quickly and cheaply with their own users. Funders can back new evaluation methods that many organizations could share, as one organization we spoke to suggested: better proxies for outcomes that can be measured cheaply and digitally, such as engagement measures that fit how a tool is meant to be used, and tools that make rigorous testing faster. Evidential, an open-source platform developed by IDinsight, is one example, letting organizations run experiments such as A/B tests within their own tools to see which version works better.
