# Level 0 research for AI funders: all content > Curated good practice on Level 0 (formative) research, for funders who review proposals for AI tools. Built by The MERL Tech Initiative. Source: https://levelzero.merltech.org. Every page is also at its own URL, listed in https://levelzero.merltech.org/llms.txt. Pages marked draft or in review have not been checked by a subject expert. Content version: 0fcb643019d8, built 2026-10-24. Record it when you cite this site; it changes whenever any page changes. --- ## E1 Digital ecosystem Questions in this bucket: - **E1.1 Connectivity.** Can the intended audience get online reliably enough, often enough and at the speeds the use case needs? - **E1.2 Device access.** How widespread is device ownership and use, and why; what kinds of devices are used? - **E1.3 Cost of use.** Can they afford the device and data the use case requires, and what measures affect this (for example free data offers from mobile operators)? - **E1.4 Phone sharing and control.** Who else uses or controls the phone, and what does that mean for meaningful engagement, privacy and safety? - **E1.5 Electricity.** Can they charge and power a device often enough for the use case? - **E1.6 Online freedom and safety.** Is there a history of shutdowns, platform blocking, censorship or surveillance that could affect the use case or put users at risk? - **E1.7 Laws and regulation.** What laws, regulations or policies (data protection, AI policy and so on) may affect the use case? > [!WARNING] > 4 of 4 pages in this bucket are not yet reviewed. Each says so at its top. ### Connectivity Page: /digital-ecosystem/connectivity > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** Can the intended audience get online reliably enough, often enough and at the speeds the use case needs? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out whether the intended users can get online where and when they would use the tool, and at the speed it needs. Connectivity means a person's own access to a mobile network or the internet [src-018 p26]. It has three parts: a network signal, a type of network fast enough for the use case (for example 2G, 3G or 4G), and a SIM card that still works [src-018 pp26-28]. Coverage varies between countries, between towns and rural areas, and between groups such as women and men [src-039 p51; src-032 p9]. Access can also fall as well as rise, with the seasons, after a drought or during political unrest [src-032 p9]. #### Why it matters for AI tools A tool tested in an office with good internet may behave very differently for users on a weak signal. NetHope's checklist for choosing an AI tool asks how the tool behaves as the network gets worse [src-011 p11]. A tool that only works on a fast, steady connection will reach the users who are already best connected, and leave out the rest [src-024 p6]. What works in one country may be impossible next door: an early guide from Plan contrasts widespread mobile internet in South Africa with its absence at the time in Togo and Mali [src-039 p51]. Connectivity also decides what the tool can do. A team building an online course found its users wanted offline access, and chose downloadable or low-bandwidth content as a result [src-031 p8]. #### What good evidence looks like - Data on the intended users' own connectivity, from a survey or direct observation, not only an operator's coverage map. Coverage maps show where infrastructure exists, not whether a given person gets a signal [src-018 pp26-27]. High coverage can sit alongside wide gaps between town and countryside and between rich and poor [src-038 p12]. - Network type and signal strength recorded where users would actually use the tool, ideally observed by a trained data collector, since many people find these hard to report [src-018 pp26-27]. - Whether users have a working SIM, and whether they use more than one. Some prepaid SIMs lapse a few months after the last top-up [src-018 pp28-29; src-032 p10]. - How often the network drops in a given place, and whether that is local or variable [src-032 p16]. - How connectivity differs by group: rural and urban, women and men, and by season or during crises [src-039 p51; src-032 p9]. - A stated target for uptime and offline use, and a plan for how the tool behaves when the connection is poor [src-007 p30; src-011 p11]. - Pilot sites chosen to reflect real connectivity, not the best-connected locations [src-007 pp40-41]. #### Red flags in a proposal - Connectivity is described only from national figures or operator coverage maps [src-018 pp26-27]. Kenya's official figures, for example, show mobile penetration above 130%, with no breakdown by gender, age, income or place [src-014 p14]. - The tool needs a steady, fast connection, and the proposal does not show the users have one [src-011 p11]. - No offline or low-bandwidth option for users with poor connectivity [src-013 p13; src-031 p8]. - The pilot runs only in a city or office with good internet [src-007 pp40-41]. - Connectivity is treated as fixed, with no thought for seasonal or crisis drops [src-032 p9]. - The proposal assumes smartphone and data use will soon be universal [src-032 p10]. #### How to find out Desk research and key informant interviews for national coverage, network operators and the market [src-032 pp15-16]. Short survey questions, or direct observation by a data collector, for network type, signal strength and SIM status at the user's own location; the EDiT guide offers question wording, some of it cognitively tested in India, Kenya and Nigeria [src-018 pp26-29]. Focus groups for how often the network fails and how people cope [src-032 p16]. A simple decision tree from Plan asks first whether power and connectivity exist; if not, the costs may outweigh the benefits and a more accessible option may be better [src-004 p17]. Testing the tool on the devices and networks users actually have [src-031 p8; src-007 pp40-41]. #### Limits and disagreements The evidence is thin on AI. Of 12 sources, four discuss AI tools [src-011 p11; src-007 pp30, 40-41; src-013 p13; src-024 p6]. None reports measured performance of an AI tool on poor networks. Most of the practical guidance comes from mobile and SMS work before generative AI [src-032 pp9-10; src-039 p51; src-004 p17]. Several sources are old. The SIMLab framework is from 2018 [src-032 p9], and the two Plan guides carry no date but describe mobile markets of around 2010 [src-039 p51; src-004 p17]. Their country examples, such as Togo and Mali, will be out of date. Plan's country briefings from that period record wide gaps in internet access by income and place in Cameroon, and internet costs that were high against Kenyan incomes [src-039 pp74, 79]. Sources weigh the issue differently. NetHope rates low-bandwidth working as important but not critical [src-011 p11]. Its guide is about staff using AI inside organisations, where office internet is more likely. For tools aimed at people in rural areas, connectivity is more likely to be a go/no-go question. The two SIMLab documents (src-032, src-031) and the two Plan documents (src-039, src-004) each come from one publisher, so they count as two voices, not four. The detailed survey guidance comes from a single guide, tested in India, Kenya and Nigeria [src-018 pp28-29]. #### Practitioner detail A reading of network type or signal strength describes one phone in one place at one moment. It cannot stand for a whole area or other times of day [src-018 p27]. Plan for several readings across places and times if the use case depends on it. Some people do not count WhatsApp or YouTube as using the internet. Questions about internet use work better when they name local apps as examples [src-005 p3]. People who use a phone may not know the term "SIM card". Use local terms and a short explanation in survey questions [src-018 p29]. Whether a SIM is still valid is hard to ask about directly; the EDiT guide uses a call made or received in the last month as a proxy [src-018 pp28-29]. Where people swap SIMs to get the cheapest network, check whether messages pass between networks [src-032 p10]. For SMS or voice fallbacks, check whether operators or aggregators can provide short codes or reverse billing, which can be slow and costly in some markets [src-032 p10]. #### Sources - **src-018**: Measuring Digital Access in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: pages 26, 27, 28, 29. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: page 11. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: pages 9, 10, 15, 16. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: page 8. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 51, 74, 79. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 17. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: pages 30, 40, 41. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: page 13. - **src-024**: AI RMF Playbook. Cited: pages 6, 31. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: page 12. - **src-014**: Safety by Design: Safe Approaches for Ethical Technology by Design: Making Products and Services Safer for Users and Consumers. Curriculum and Facilitator Guide. IREX, 2025. Cited: page 14. - **src-005**: The Devil is in the Details: Cognitive interviewing to strengthen quantitative surveys. Evidence for Digital Transformation (EDiT) Consortium, 2025. Cited: page 3. ### Cost of use Page: /digital-ecosystem/cost-of-use > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** Can they afford the device and data the use case requires, and what measures affect this (for example free data offers from mobile operators)? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out whether the intended users can pay for what the tool needs: the phone, its repairs, and the airtime, SMS or data to keep using it. For many people, and for women and girls in particular, the running cost of data can matter more than the price of the phone [src-018 p32]. A person may own a phone and a SIM and still be unable to use it because there is no credit on it [src-018 p32]. Cost is tied to who holds the money: women often have less money of their own, so others often pay for their phone and top-ups [src-032 p7; src-018 pp30-33]. Ask, too, what makes the tool cheaper or free to use, such as toll-free numbers or free short codes [src-038 pp17, 21-22]. #### Why it matters for AI tools Accurate AI advice has no effect if the user cannot afford the data, airtime or power to receive it [src-003 p6]. Generative AI tools can cost users more than simpler tools. Girl Effect gives the example of a user whose battery and data are drained by an AI chatbot where a scripted one would have served [src-012 p15]. Those who can afford reliable power and internet will gain most from such tools, so they can widen digital and gender divides [src-012 pp16, 22]. Channel choice is also a cost choice. Smartphone ownership is low in sub-Saharan Africa and South Asia, and lower still for women, and many AI tools need a smartphone app. SMS or voice chatbots avoid the need for a smartphone, but SMS charges are too high in some countries [src-015 p37]. AI models that run on the phone without internet need costlier handsets than most users can buy [src-015 p37]. Charging users can shut out the people a service is for. Plan's guides warn that user charges, even just the cost of using one's own phone, can exclude those who most need support, and that fees fall hardest on young people and women, who control less household spending [src-039 p16; src-004 pp20-21]. In some rural settings women are left out by usage costs because they are not expected to handle money [src-039 p37]. Cost changes who uses a service. When a radio programme in Nepal made its feedback number toll-free, use rose to over 20,000 messages in one day [src-038 p17]. In Benin, the cost of an SMS was thought to keep some people from reporting violence, so the team sought a free short code [src-038 p22]. #### What good evidence looks like - Spending on airtime, SMS and data, not only device ownership, for the intended users [src-018 p32]. - Whether users have credit on their phone now, when they last topped up, and who paid [src-018 pp32-33]. - Who paid for the phone and its repairs, with male and female relatives recorded separately so the data can be broken down by gender [src-018 pp30-32]. - How people get by without credit, for example reverse calls, where the receiver pays, or sharing another phone's connection as a hotspot [src-020 pp60, 66]. - How regular income is, and the time people spend travelling to buy airtime or charge a phone [src-032 pp6-7]. Seasonal income, drought or conflict can cut people's ability to pay for airtime for a time [src-032 p9]. - Whether phones are for individual, family or community use, and who owns and pays for them [src-039 p39]. - Local prices of airtime, SMS, mobile and fixed internet, and electricity, and whether free messaging options exist [src-004 pp15, 34]. - The cost of the tool to the user on each channel, with a plan to make it free or cheap, for example toll-free numbers, free short codes or low-cost airtime from operators [src-038 pp21-22, 27; src-015 p37]. - Where the project hands out phones, agreements with users and guardians on use, loss and data costs [src-037 p20]. #### Red flags in a proposal - Access is described only as phone ownership, with no data on airtime and data spending [src-018 p32]. - The tool needs a smartphone and a data plan, with no evidence users can afford either [src-015 p37]. - Users are expected to pay for SMS, data or outgoing calls, and the proposal does not show this is affordable for them [src-038 pp17, 22; src-020 p66]. - A generative AI design is chosen where a lighter tool would cost users less, with no comparison [src-012 pp15-16]. - Costs are not broken down by gender, though women's access to money differs [src-018 pp30-32; src-032 p7]. - The tool is free to the project but users pay to use it, and the proposal does not show who that leaves out [src-039 p16; src-004 pp20-21]. #### How to find out Survey questions on device, repair, credit and data spending, with local terms for credit and top-up; the EDiT guide gives worded questions and notes which need testing [src-018 pp30-34]. A local checklist of prices, filled in with technical colleagues [src-004 pp15, 34]. Focus groups and interviews on how income, seasons and travel affect top-ups [src-032 pp6-7]. Conversations with mobile operators about free or low-cost short codes and airtime [src-038 p27]. #### Limits and disagreements No source in the corpus covers free data offers from mobile operators (zero-rating, where operators do not charge data for selected services), which the E1.3 question asks about. This is a gap. Most sources predate generative AI. Plan's country briefings from around 2010 show how far costs differ between countries: in Cameroon the cost of phones, subscriptions and calls was prohibitive for most people, while in Kenya new operators had cut the cost of mobile use [src-039 pp74, 79]. Figures of that age are only a reminder to check current local prices. The UNICEF paper is from 2013 [src-038 p17] and the Plan guide is undated [src-004 p15]. Only two sources discuss the cost of AI tools to users [src-012 p15; src-015 p37]. Girl Effect's point that AI tools cost users more is a stated risk with an illustrative example, not a measured finding [src-012 p15]. Much of the survey guidance comes from two guides by one consortium, the EDiT guides from the University of Cape Town (src-018, src-020). Their questions were developed for the Digital Access and Use Project and many are marked as needing testing [src-018 p31]. The Kenya findings on reverse calling and hotspots come from a single setting [src-020 p66]. Digital Green asks how lowering cost barriers changes women's adoption of digital tools, but as a research question, not a finding [src-016 p3]. The corpus has little direct evidence on how much cost alone limits use, compared with norms and control of the phone (see E1.4 phone sharing and control). #### Practitioner detail Many people cannot say what their phone cost, because a relative paid, it was a gift, or it was handed down [src-018 p31]. Repair costs matter most where a programme gives out devices [src-018 p31]. People often cannot separate spending on credit from spending on data, because the two are sold together. Spending by others on their behalf is also hard to report [src-018 p33]. In Kenya, asking how much credit someone had was felt to be intrusive [src-020 p66]. Where research asks people to use their own phones, pay them back for any data or airtime they use [src-020 p18]. #### Sources - **src-018**: Measuring Digital Access in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: pages 30, 31, 32, 33, 34. - **src-020**: Measuring Digital Skills in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: pages 18, 60, 66. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 15, 16, 22. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 20. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: page 37. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: page 6. - **src-016**: Gender Formative BIG Research questions. Cited: page 3. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: pages 12, 17, 21, 22, 27. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 15, 20, 21, 34. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: pages 6, 7, 9, 10. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 16, 37, 39, 74, 79. ### Online freedom and safety Page: /digital-ecosystem/online-freedom-and-safety > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** Is there a history of shutdowns, platform blocking, censorship or surveillance that could affect the use case or put users at risk? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out whether using the tool could expose people to state or non-state control of the internet, or to abuse online. This covers three things. First, whether governments or armed groups cut off networks or power, and when [src-031 p5]. Second, censorship and surveillance: who owns the networks and who can read what passes over them [src-032 p11; src-031 p5]. Third, online abuse, especially technology-facilitated gender-based violence (TFGBV): harm done or made worse through digital tools, which falls mostly on women and girls [src-014 pp16-17]. Laws on free speech and privacy matter, but they may not be upheld in practice [src-031 p5]. #### Why it matters for AI tools A tool can put its users at risk. Data that would be harmless in one place can be dangerous in the wrong hands in another, and some groups face extra surveillance, for example activists or LGBTQ people whose location data could expose them [src-032 p11]. Even where the risk of interception is low, people may avoid a channel they fear is watched, or one linked to a political or religious group [src-032 p11]. An AI tool might also be used, by the organisation or by others, to support censorship, disinformation or surveillance of vulnerable people [src-011 pp7-8]. Principles for Digital Development lists digital repression through surveillance and censorship among the main harms of digital work, and notes these harms are less understood for AI [src-010 p10]. Access to the tool itself can be cut. A provider may block users in some countries, or be banned or sanctioned by a government the project works under [src-011 pp7-8]. Online abuse also shapes who uses a tool. Fear of abuse leads many women to censor themselves or withdraw from online services [src-014 p18]. In some places, norms limit women's phone use partly out of fear for their reputation; in others, women use phones freely but meet harassment [src-019 p7]. #### What good evidence looks like - A record of network or power shutdowns in the area, who ordered them, and around which events [src-031 pp5-6]. - Who owns and controls the networks and main channels, and whether any are tied to political or religious groups [src-031 p5; src-032 p11]. - Laws on free speech, privacy and data, and evidence on whether they are enforced [src-031 p5]. - Whether any user group faces extra surveillance, and what data it would be dangerous to collect from them [src-032 p11]. - Whether users change or hold back what they send because they worry who might read it [src-032 p18]. - Local evidence on online abuse, broken down by gender, using the terms each audience uses [src-014 pp14-16; src-019 p7]. - For an AI provider: whether it restricts access from the countries of use, what happens if it is banned or sanctioned, and whether it has ties to military or intelligence agencies [src-011 pp7-8]. - A plan to review the risks when the context changes, for example if censorship rises [src-037 p27; src-039 p21]. #### Red flags in a proposal - The tool asks users to report on sensitive issues, such as rights abuses, in a repressive setting, with no assessment of the danger to them [src-039 p21]. - It collects location or identity data from groups at risk of surveillance [src-032 p11]. - The legal context is described from laws on paper only [src-031 p5]. - There is no plan for a network shutdown or for losing access to the provider [src-031 pp5-6; src-011 pp7-8]. - Online abuse is not considered, though the users include women, girls or other groups at risk [src-014 p18; src-019 p7]. - The risk assessment is done once, with no trigger to repeat it [src-037 p27]. #### How to find out Desk research on conflict history, censorship, free speech and privacy law, and who runs the networks [src-031 p5]. Key informant interviews with officials, to test whether laws and policies hold in practice [src-031 p5]. Focus groups with community members, and short survey questions on whether network or power access is ever cut and why [src-031 pp5-6]. Focus groups and interviews on whether fear of being read changes what people send [src-032 p18]. A risk assessment combined with a data protection impact assessment (a formal review of how a project's use of personal data could harm people), repeated when the context changes [src-037 p27]. #### Limits and disagreements Only one source addresses AI directly, and it is a checklist for organisations choosing tools, not a study [src-011 pp7-8]. Principles for Digital Development says AI harms in this area are less understood [src-010 p10]. None of the sources reports a case of an AI tool affected by a shutdown or by surveillance. The guidance on shutdowns and surveillance comes from SIMLab's 2018 framework and its example assessment, so it is one voice (src-032, src-031). The example is a community policing project across 12 countries [src-031 p4]. Evidence on online harms is thin and mostly from high-income settings [src-019 p7]. The figures in the IREX guide come from Kenya and are cited without method details [src-014 p18]. Sources differ on anonymity. Girl Effect notes it can lower risk to girls on some platforms and has increased trolling of girls and women on others [src-037 p38]. Projects need to judge this for each channel. #### Practitioner detail Groups in Kenya name the same harms differently. Donors and international NGOs say TFGBV; some local groups say online gender-based violence; survivors and support services name tactics such as cyberstalking or doxxing; police and courts use the terms in Kenya's cybercrime and ICT laws [src-014 pp14-16]. Research on online harms should check which words each audience uses. Laws on paper may give a route to redress without being enforced well. Kenya's Computer Misuse and Cybercrimes Act 2018 covers cyber harassment and the sharing of intimate images, but IREX notes that enforcing it in practice can be hard [src-014 p46]. The IREX guide lists forms of TFGBV, including harassment, image-based abuse such as deepfakes, cyberstalking and doxxing (publishing someone's private details) [src-014 pp15, 17]. Abuse often moves from online to offline [src-014 p16]. #### Sources - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: pages 4, 5, 6. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: pages 11, 18. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: pages 7, 8. - **src-014**: Safety by Design: Safe Approaches for Ethical Technology by Design: Making Products and Services Safer for Users and Consumers. Curriculum and Facilitator Guide. IREX, 2025. Cited: pages 14, 15, 16, 17, 18, 46. - **src-019**: Measuring Digital Harms in Low and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2025. Cited: page 7. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: pages 27, 38. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: page 21. - **src-010**: Principles for Digital Development. Digital Impact Alliance (DIAL), 2024. Cited: page 10. ### Laws and regulation Page: /digital-ecosystem/laws-and-regulation > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** What laws, regulations or policies (data protection, AI policy and so on) may affect the use case? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out which laws, rules and policies apply to the AI tool in each country where it will be used. The main ones are data protection law, any AI-specific law or strategy, and sector rules such as those for health data or bulk messaging [src-032 p10; src-012 p20; src-013 pp8-9]. Check national law, not only international frameworks such as the EU AI Act or GDPR (the EU's General Data Protection Regulation) [src-025 pp18, 37; src-037 pp35-36]. These rules change quickly, so the answer needs checking again during the project [src-012 p20; src-010 p3]. A Level 0 review should also cover government policies and national strategies that the tool could support or clash with [src-010 p3; src-013 p9]. #### Why it matters for AI tools Teams that do not understand the technology they are using can break data privacy or AI rules without knowing it [src-012 p22]. Many AI tools send prompts and documents to a provider abroad. That raises questions about where data is stored, whether it is used to train the provider's models, and whether a foreign government could demand access to it [src-011 pp7, 12-13]. Sanctions or export controls can stop staff or partners in some countries from using a tool at all [src-011 p7]. A government ban on a provider can cut off the service and the data held in it [src-011 p8]. Breaking the law can bring fines, a forced shutdown, or harm to young users [src-037 p36]. Some rules also block a delivery channel: in some places, regulators limit automated outbound calls at unsocial hours, and those may be the only hours when some women have a phone [src-018 p22]. In many countries, government policy restricts mobile phones in schools, so a school project may need special permission [src-004 p14]. AI tools that people with poor connectivity or a disability struggle to use can also create legal risk, for example in hiring decisions that affect disabled people [src-024 p6]. Funders' own rules count too. Some donors require that all data collected with their money is handed over for sharing and reuse; SIMLab gives USAID as an example. That adds liability and risk for vulnerable people, who may find it hard to give meaningful consent [src-030 p22]. #### What good evidence looks like - The proposal names the data protection law in each country of use, for example Kenya's Data Protection Act 2019 or India's Digital Personal Data Protection Act 2023, and says what it requires of the project [src-014 p46; src-028 p28]. - It lists AI-specific laws, strategies or codes that apply, such as a national AI strategy or a national standards body's AI code of practice [src-013 p9]. - It maps where data is stored and where it moves, across every country involved, and checks national rules on storing and transferring data [src-032 p11; src-011 p7; src-030 p21]. - It records the contract terms with any AI provider on data residency, use of data for model training, and the data processing agreement (the contract setting out how the provider handles personal data) [src-011 pp7, 12]. - It lists third-party models, data and software, and the legal risks they carry, including possible breach of someone else's intellectual property [src-024 p90]. - It covers sector and channel rules, such as licences for bulk SMS, ID rules for SIM registration, limits on automated calls, or limits on phones in schools [src-032 p10; src-018 p22; src-004 p14]. - It includes legal advice from a qualified lawyer in each jurisdiction, or a plan to get it [src-028 p29; src-032 p11; src-037 p36]. - It states whether a risk or rights assessment is required for the intended use, and whether one has been done [src-011 p13; src-024 pp6-7]. - It includes a privacy impact assessment (a structured check of how a feature handles personal data), run with a security review. That check covers data minimisation, consent, access rights, retention and deletion, third-party services, and the law's rules on data requests and breach notification [src-014 p38]. - It explains how consent will be obtained and how the law's consent rules will be met [src-028 pp28-29]. - It checks whether the laws are applied in practice, not only what they say on paper [src-031 p5]. #### Red flags in a proposal - Only EU or international frameworks are cited, with no mention of national law in the countries of use [src-025 pp18, 37; src-037 p36]. - No mention of where data will be stored, or of whether the AI provider can use project data to train its models [src-011 pp7, 12]. - Company ethics principles or a provider's own code are presented as if they were legal compliance [src-035 p8]. - The project works across borders but names the law of only one country [src-032 p11]. - Laws covering children's data, safeguarding or mandatory reporting of abuse are missing where the users include children [src-037 pp15, 35; src-039 p43]. - The tool handles reports on sensitive topics such as health, conflict, elections or human rights, and the proposal does not ask whether the act of reporting puts anyone at risk [src-039 p43]. - Legal review is treated as a one-off task, with no plan to track new rules [src-012 p20; src-010 p3]. #### How to find out Desk review of national data protection laws, AI strategies, sector regulations and published legal trackers [src-013 p8; src-037 p36]. For a 12-country community policing project, SIMLab's desk questions covered free speech law, broadcast licensing, access to information, data privacy law, who runs the networks, and whether state or other actors cut networks or power, and when [src-031 p5]. Legal advice from a licensed lawyer in each country, including pro bono counsel where budgets are small [src-028 p29; src-032 p11]. A map of data storage and data flows through the project [src-032 p11]. Published risk and compliance tools, such as the US NIST AI risk management framework or an EU AI Act compliance checklist, used as prompts rather than as a substitute for local law [src-012 p25; src-024 p6]. Questions put directly to AI providers on data residency, training use, sanctions and compliance with each country's law [src-011 pp7, 12-13]. Conversations with local actors already working on the problem, to learn which government policies and strategies apply [src-010 p3]. Early contact with relevant government officials, to build support and secure any permissions [src-004 p14]. Desk research can miss the gap between law and practice. SIMLab planned interviews with officials about the policies found on paper, and survey questions such as whether the mobile network or power is ever cut off, and why [src-031 pp5-6]. #### Limits and disagreements Several sources name EU and international frameworks first. The NetHope toolkit lists the EU AI Act, GDPR and OECD principles, and mentions local law only later, as a deployment check [src-025 pp18, 37]. The NetHope PESTLE guide is wider but still leads with EU, UK and US law [src-011 p12]. The NIST playbook draws its legal examples from the United States [src-024 pp6-7]. Funders working in low- and middle-income countries may need to ask for local legal review explicitly. Country detail is thin. Kenya appears through two IREX documents [src-013 p9; src-014 pp38, 45-46], India through one playbook [src-028 pp28-29], and South Africa and Rwanda through a passing mention [src-037 p35]. The India material describes draft rules that were under consultation when the playbook appeared, so it may be out of date [src-028 p29]. The child consent rules described by Girl Effect are EU and UK law as of 2018 [src-037 pp16, 28-29]. Sources disagree on what counts as enough. The Pollicy handbook argues that ethics codes set by companies cannot protect rights on their own, and that legislation alone covers only harms that can be proven [src-035 pp8-9]. It also argues that individual consent is given too much weight and that rights over data can be collective as well as individual, a view drawn from African traditions and taken up in the African Union's data policy framework [src-035 pp6, 15]. The India playbook, by contrast, treats explicit individual consent as the core legal duty [src-028 p28]. Girl Effect takes a third line: under the GDPR, consent is one of several lawful bases for processing data, and legitimate interest may protect a child better [src-037 p28]. Several points rest on older or non-AI sources. The three SIMLab documents (src-030, src-031, src-032) cover SMS and mobile projects and count as one voice. Two date from 2018 and the third carries no date [src-030 p22; src-031 p5; src-032 pp10-11]. The two Plan guides (src-004, src-039) are undated, describe ICT projects of around 2010, and also count as one voice [src-004 p14; src-039 p43]. The Girl Effect safeguarding guide is also from 2018 and is not about AI [src-037 pp35-36]. Both Girl Effect sources [src-012 p20; src-037 p35] share authors with other MTI-linked sources, so their agreement with each other is less independent than it looks. The point about automated calls comes from a single EDiT guide on digital access, not from AI work [src-018 p22]. The AAAS decision tree describes the EU AI Act as a proposal, so its account predates the final law [src-001 p5]. #### Practitioner detail Three forms of regulation are worth separating: law made and enforced by the state, self-regulation by companies or industry bodies, and co-regulation, where industry sets standards inside legal goals under state supervision [src-035 pp8-9]. A proposal that relies on a provider's own code is relying on the weakest of these [src-035 p9]. Kenya's Data Protection Act 2019 sets principles such as purpose limitation and data minimisation, and gives people rights to see, correct and delete their data [src-014 p46]. The EU approach sorts AI systems into four risk tiers: unacceptable, high, limited and minimal. The high tier includes uses in education and vocational training, employment, essential services, law enforcement, migration and the justice system [src-001 p5]. Many development uses of AI fall in these areas. For children, the GDPR sets the age at which a child can consent to data processing at 16, and lets EU countries lower it to no less than 13; the UK uses 13 for online services [src-037 p16]. Below that age, a service relying on consent needs a parent or guardian's consent, and must make efforts to check age that match the risk of the processing [src-037 pp28-29]. Reporting tools for violence raise a specific tension. A Plan SMS pilot for reporting violence needed to strip identifying details before publishing reports on a public map, while keeping full records for local authorities. It also had to protect the privacy of people reporting in small communities where everyone knows everyone else, and consulted children and young people on how to do so [src-039 p88]. Where national law conflicts with EU or UK law, organisations may need specific advice on which to follow [src-037 p36; src-032 p11]. Health data and other personal data often carry extra rules that should be scoped early [src-032 p21]. #### Sources - **src-010**: Principles for Digital Development. Digital Impact Alliance (DIAL), 2024. Cited: page 3. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: pages 7, 8, 12, 13. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 20, 22, 25. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: pages 8, 9. - **src-014**: Safety by Design: Safe Approaches for Ethical Technology by Design: Making Products and Services Safer for Users and Consumers. Curriculum and Facilitator Guide. IREX, 2025. Cited: pages 38, 45, 46. - **src-018**: Measuring Digital Access in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: page 22. - **src-024**: AI RMF Playbook. Cited: pages 6, 7, 90. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: pages 18, 37. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 28, 29. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: pages 10, 11, 21. - **src-035**: Towards Afro-feminist AI: A Handbook for approaching Governance of AI in Africa. Cited: pages 6, 8, 9, 15. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: pages 15, 16, 28, 29, 35, 36. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 21, 22. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: pages 5, 6. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 14. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 43, 88. - **src-001**: Decision Tree for the Responsible Application of Artificial Intelligence (v1.0). AAAS Center for Scientific Responsibility and Justice (CSRJ). Cited: page 5. ### Guidance for AI assistants 4 of 4 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E2 AI trust and norms Questions in this bucket: - **E2.1 AI usage.** Which AI tools, if any, does the audience use, how often and for what? - **E2.2 AI trust.** How does the audience feel about AI and its outputs? Do they trust it enough, or too much, for this use case? - **E2.3 AI literacy.** How much does the audience understand about AI, how it works, its risks and how to use it well? - **E2.4 AI acceptability.** How does the audience feel about AI for this specific use case? How much will they share with an AI tool on this topic? - **E2.5 Social norms.** How do influential people, organisations or institutions in the audience's life affect their likely use of AI? > [!WARNING] > 2 of 2 pages in this bucket are not yet reviewed. Each says so at its top. ### AI literacy Page: /ai-trust-norms/ai-literacy > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** How much does the audience understand about AI, how it works, its risks and how to use it well? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out what the intended users understand about AI: what it can and cannot do, that it can be wrong, and how to use it well for this task. The Digital Futures Lab playbook calls this critical AI literacy: an awareness of AI's strengths and limits, fitted to the user's needs and context [src-028 p61]. AI literacy rests on general digital skills, so find out those too [src-028 p61; src-020 pp7-9]. Many people in low-resource settings lack basic phone skills that designers take for granted [src-020 pp57, 59]. Some users do not realise they are talking to an AI rather than a person [src-013 p11]. #### Why it matters for AI tools Users who do not know AI can be wrong may trust a chatbot too much, think less critically and make poor decisions [src-013 p11]. This matters most where users have few other ways to check an answer [src-028 p61]. Most AI tools need digital and AI literacy that low-income and marginalised groups may lack. Measuring the gap at the start shows whether AI is the right approach, or whether simpler technology or a non-digital option would work better [src-028 p15]. Low literacy also wastes what the tool offers. Digital Green lists a failure where a tool's advanced features go unused because users cannot yet see how to benefit from them [src-003 p7]. Users are seldom taught how to write prompts or how AI tools work [src-012 p8]. #### What good evidence looks like - The users' digital skills, measured with questions built for phone users, not computer users [src-020 pp9-12; src-023 pp1, 3]. - Whether users can do key tasks alone or only with help [src-021 pp3-4]. - What users understand about AI: that it can be wrong, that they may be talking to a machine, and what happens to what they share [src-013 p11; src-028 p63]. - Whether the words used to explain the tool make sense to users. In India, many respondents did not know words like "hacking", "personal data" or "privacy policy" [src-019 p36]. - A plan for AI literacy if gaps exist: what to teach, how often, who delivers it, and the time and budget for it [src-028 pp61-64]. - How the tool explains its outputs, tested with the users, for example community health workers [src-028 p44]. #### Red flags in a proposal - The proposal cites national figures on computer skills as evidence of the audience's digital skills. These leave out people who go online only by phone [src-023 pp1, 3]. In most of 40 low- and middle-income countries, fewer than a fifth of women used a computer, while phone ownership was far higher, so computer-based figures describe mostly the wealthiest and best educated [src-023 p1]. - The design assumes users can do basic tasks, such as saving contacts or freeing storage, without checking [src-020 pp57, 59]. - No plan to tell users the tool can be wrong, or that they are talking to an AI [src-028 p63; src-013 p11]. - AI literacy is a one-off training session [src-028 p63]. - No time or budget for building literacy before users are expected to adopt the tool [src-028 pp63-64]. #### How to find out Survey questions on digital skills designed for mobile-first users in low- and middle-income countries; the EDiT guide offers a question bank, tested or in draft, across information, communication, content creation, safety and problem solving [src-020 pp9-12]. Separate response options for doing a task alone and doing it only with help [src-021 pp3-4]. The EDiT guide also sets out how to observe people doing tasks on the phone they use most, after a short check that the phone works [src-020 pp18, 65-66]. Cognitive interviews (testing how people understand each question) on the words used to describe AI, data and risk [src-019 pp36, 39]. Participatory discussion of existing practices and skills, as a starting point for design [src-039 p39]. Testing the tool's explanations with users before launch [src-028 p44]. #### Limits and disagreements The evidence on AI literacy itself is thin. The EDiT guides measure general digital skills and include no questions on AI [src-020 pp7-9]. The AI-specific guidance comes mostly from one Indian playbook [src-028 pp15, 44, 61-64], and its one study on AI explanations involved a simulated tool [src-028 p44]. Girl Effect asks teams to offer AI literacy content even just to test interest, which suggests little is known about what users want [src-012 p24]. Four sources come from one consortium, EDiT at the University of Cape Town (src-019, src-020, src-021, src-023), tested in India, Kenya and Nigeria. Their findings on skills come from cognitive testing, not a representative survey [src-020 pp57, 59]. Sources differ on what literacy is for. The Digital Futures Lab playbook frames critical AI literacy as building agency and challenging power, with questions such as who benefits [src-028 p61]. Girl Effect and IREX frame it more as safe and responsible use [src-012 p20; src-013 p11]. Both views can shape a funder's ask. The Plan report on judging what is true online predates AI and draws on a blog by Linda Raftree, MTI's founder [src-039 p39]. #### Practitioner detail In cognitive testing in low-literacy settings, many people could not save or edit contacts, so depended on others to make calls. Some could install apps but not delete files, and ran out of storage. Many joined WiFi networks someone else had set up [src-020 pp57, 59]. People with phone problems often ask family, friends or a mobile shop [src-020 p51]. For AI literacy programmes in low-resource settings, the playbook reports that short, regular sessions run by community peer educators over a long period work best [src-028 p62]. It sets honesty about risks and likely errors as the minimum, and advises plain language without jargon [src-028 p63]. Explaining to users how their data will be used to train the system can build trust [src-028 p63]. A cited study of community health workers in rural India found they struggled to understand simplified AI explanations for newborn jaundice but still wanted them. Suggested fixes included less text and local examples and analogies [src-028 p44]. #### Sources - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 15, 44, 61, 62, 63, 64. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 8, 20, 24, 28. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: pages 11, 13. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: page 7. - **src-020**: Measuring Digital Skills in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: pages 7, 8, 9, 10, 11, 12, 18, 51, 57, 59, 65, 66. - **src-021**: Measuring digital skills: Best practices from cognitive interviews in India, Kenya and Nigeria. Evidence for Digital Transformation (EDiT) Consortium, 2025. Cited: pages 3, 4. - **src-023**: The importance of a mobile-first approach for measuring digital skills in low- and middle-income countries: A MICS-6 survey data analysis for 40 countries. Evidence for Digital Transformation (EDiT) Consortium, 2025. Cited: pages 1, 3. - **src-019**: Measuring Digital Harms in Low and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2025. Cited: pages 36, 39. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: page 39. ### Social norms Page: /ai-trust-norms/social-norms > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** How do influential people, organisations or institutions in the audience's life affect their likely use of AI? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out who shapes whether the intended users will try an AI tool, and what those people think about it. Social norms are the unwritten rules a group holds about what behaviour is acceptable [src-022 p1]. They cover what people believe others do and what they believe others approve of [src-022 p1]. The people who matter can be close family, such as husbands, parents and in-laws, or community figures such as teachers, health workers and religious leaders [src-026 p4]. Some of them act as gatekeepers: they can open or close a person's access to new information [src-026 p4]. #### Why it matters for AI tools An AI tool can give correct advice that the user is not allowed to act on. AI farm advice may assume the user owns the land, controls the money or can decide alone, when household roles say otherwise [src-003 p8]. Advice that ignores these limits can go unused or cause conflict at home [src-003 p8; src-003 p10]. Using the app can itself expose women to monitoring, harassment or violence [src-003 p11]. Norms also limit privacy of use: in one 2018 survey cited by J-PAL, only a fifth of respondents thought it acceptable for a woman to use a phone without supervision [src-015 p37]. Norms held by institutions matter as well as those held at home. A young woman used an AI chatbot on gender-based violence law, then cited what it told her at a police station to seek a protection order. The police took offence and turned her away. Digital Futures Lab concludes that the chatbot's plan needed to involve the police and the legal system, not only women users [src-028 p22]. Endorsement by trusted people can decide uptake. In an ongoing Indian study of AI flood forecasts, villages that also had trained local volunteers received warnings sooner and trusted them more than villages that got phone alerts alone [src-015 p15]. Older non-AI studies point the same way: in India, SMS vaccine reminders alone did nothing until well-known local people promoted them [src-015 p39]. In a health project in Eastern Africa, city doctors and officials failed to win villagers over to a new practice; uptake came once local healers carried the message [src-027 pp34-35]. Where norms limit women's contact with male staff, women outreach workers can be needed to reach women users of an AI service [src-028 p54]. Using a new tool can also change how others see the user. A guide for child-focused projects warns that girls may be judged harshly for using some technologies [src-004 p13]. #### What good evidence looks like - The proposal names the people who influence the target users' decisions, beyond the users themselves [src-026 p4; src-004 p13]. - The team has asked those influencers directly what they think of the tool and what it would change for them [src-004 p13; src-026 p8]. - Findings separate a user's own views from what they think others do and what they think others approve of [src-022 p1]. - Evidence checks whether using the tool is socially acceptable for women and other marginalised users, not only whether they can access it [src-016 p2; src-028 p54]. - The design of the advice reflects who in the household holds decision power [src-003 p8]. - Findings are reported by site or group, since the same question can get very different answers in different places [src-026 p18]. - Views from several kinds of respondent are compared, rather than relying on officials or leaders alone [src-026 p8]. - Where the tool asks users to act against current norms, the plan reaches the people around them too, such as husbands and extension agents, and reports outcomes by gender [src-028 pp21-22]. #### Red flags in a proposal - The proposal assumes users can act on advice alone, with no mention of spouses, parents, in-laws or local leaders [src-003 p8; src-026 p4]. - Rollout relies only on phone messages, with no plan to involve trusted local people [src-015 p15; src-015 p39]. - Gatekeepers such as officials or leaders chose which users the team spoke to [src-026 p6]. - Norms were measured with a single attitude scale and no attempt to learn why views persist or change [src-026 p7]. - Findings from one district or country are applied to another without checking [src-022 p1; src-026 p18]. - The proposal assumes a phone or app will replace in-person contact in a culture that values meeting face to face [src-039 p85]. - Women's phone access is estimated from what people believe is normal. In Bihar, most respondents thought most married women had their own smartphone, when only about a third did [src-022 p7]. #### How to find out - **Stakeholder mapping.** List everyone who could affect whether the tool is accepted, then ask each group what the change means for their own work [src-004 p13]. Record each group's position, to find opinion leaders, allies and opponents, and include other donors working on the issue [src-006 p36]. - **Questions about taboos.** Ask what prejudices, fixed opinions or taboos surround the issue, and whether the community is open to change [src-006 p36]. - **Influence and channel maps.** Venn diagrams (overlapping circles drawn with participants) show which people and institutions hold influence and how information passes between them. Include informal channels, which often matter more than formal ones [src-027 p34]. - **Household phone maps.** Map who in the household owns the phone and who controls its use [src-016 p3]. - **Trusted local workers.** Extension workers from the community often understand local gender and social norms and can spot barriers to adoption [src-028 p53]. - **Interviews with family and community members.** Speak to parents, spouses, in-laws and local influencers as well as users, and cross-check what each group says [src-026 p4; src-026 p8]. - **Questions about behaviour first.** Ask what people do and when, then what they think is right, then what happens to those who do not conform [src-026 p7]. - **Indirect questions.** Tell a short story and ask how an ordinary person in it would act, ask what would happen to someone who broke the rule, or ask who most influences the respondent's decisions [src-026 p7]. - **Surveys with matched questions.** Ask the same question about women and about men and compare the answers [src-022 p2]. - **Role play.** Act out the arrival of a new tool between two groups, such as pupils and teachers, to bring out hopes and fears [src-004 p33]. - **Network interviews.** Interview a married couple and both sets of parents separately to see who holds influence [src-026 p18]. #### Limits and disagreements - **Mostly not about AI.** Of eleven sources, three concern AI tools: AI farm advice [src-003 p8], AI flood alerts [src-015 p15] and responsible AI practice, including the chatbot case [src-028 pp22, 54]. The rest are about phones, SMS, the internet or gender norms in general. The evidence on norms is mostly about phones and the internet, not AI. Nothing here shows whether influencers treat AI tools differently from other phone services. - **Countries.** Field evidence comes from India (the Bihar survey and J-PAL studies), Ghana (one J-PAL study), Ethiopia, Uganda, Nepal and Viet Nam (ODI fieldwork), Senegal (Plan staff) and Eastern Africa (one World Bank example) [src-022 p1; src-015 p39; src-026 p4; src-026 p18; src-039 p85; src-027 p35]. Some points give no country. None of it comes from Latin America. - **Age of evidence.** The World Bank guide dates from 2009, the UNICEF review from 2013, the ODI field guide from 2015 and the SDC guide from 2016. The Bihar survey ran in 2024 and 2025 and its authors say it applies only to Bihar [src-022 p1]. - **Gender focus.** Most sources study norms that limit women and girls. Norms affecting men, older people or disabled people are barely covered. - **Who matters most varies.** In Bihar, a husband's approval mattered more to women's smartphone ownership than a mother-in-law's [src-022 p5]. ODI found in-laws held strong control in Nepal but little in the Hmong community of northern Viet Nam [src-026 p18]. No single list of influencers will fit every site. - **Confront or work around?** One UNICEF example shows a phone service that let young women seek jobs from home without challenging family limits on their movement [src-038 p19]. Other sources treat changing household decision power as a goal [src-016 p2]. Proposals should say which they intend. - **Measurement.** The Bihar survey uses scored survey answers [src-022 p2]. ODI says such scales show individual views but not why norms hold or shift, and relies on qualitative methods instead [src-026 p7]. - **Shared voices.** src-038 and src-039 share MTI-linked authors, so their agreement is less independent than it looks. src-003 and src-016 come from the same organisation. The J-PAL vaccine and mobile banking findings are summaries of other studies [src-015 p39]. #### Practitioner detail The Bihar survey of 13,500 adults found most men and many women thought men need their own phone while sharing is acceptable for women [src-022 p1; src-022 p4]. Women's views were more neutral than men's on smartphones, internet and payment apps [src-022 p4]. Women with neutral views were more often literate, better educated and under 40 [src-022 p5]. Predicted smartphone ownership was low for all women, but highest when both husband and mother-in-law approved [src-022 p5]. Fewer than 1% of women who owned a smartphone said both disapproved [src-022 p6]. Approval also shapes how women use phones. Of women who had used the internet, 79% had approval from both; only 6% of women had ever paid by phone, and 88% of those had approval from both [src-022 p6]. This matters for tools that involve money or sensitive topics. Education was the strongest predictor of ownership: a graduate was about 35 percentage points more likely to own a smartphone than a woman with no schooling. Wealth mattered less than education and household approval [src-022 pp7-8]. People often find it easier to talk about local customs and traditions than about norms. Comparing past and present helps older respondents describe change [src-026 p7]. Respondents also tend to present themselves well, and may speak more frankly about their community than about their own family [src-026 p8]. Some influencers are easy to miss: in Uganda, elders and paternal aunts played a strong part in upholding norms [src-026 p8]. #### Sources - **src-026**: Doing qualitative field research on gender norms with adolescent girls and their families. Overseas Development Institute (ODI), 2015. Cited: pages 4, 6, 7, 8, 18. - **src-022**: Measuring attitudes and norms related to women's use of phones. Evidence for Digital Transformation (EDiT) Consortium, 2025. Cited: pages 1, 2, 4, 5, 6, 7, 8. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: pages 8, 10, 11. - **src-016**: Gender Formative BIG Research questions. Cited: pages 2, 3. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 13, 33. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: page 85. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 15, 37, 39. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 21, 22, 53, 54. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: page 19. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: page 36. - **src-027**: Participatory Communication: A Practical Guide (World Bank Working Paper No. 170). The World Bank, 2009. Cited: pages 34, 35. ### Guidance for AI assistants 2 of 2 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E3 Language and literacy Questions in this bucket: - **E3.1 Preferred languages.** Which languages does the audience prefer to write in, and to speak in? - **E3.2 Code-switching.** In multilingual contexts, when, how and why does the audience mix languages? - **E3.3 Literacy.** How well can the audience read and write, and how does that affect the use case? - **E3.4 Modality.** Which ways of communicating (text, voice, voice notes, video) does the audience prefer and use comfortably? - **E3.5 Model performance.** How well do the proposed language models perform in the audience's languages, code-switching and modalities? > [!WARNING] > 2 of 2 pages in this bucket are not yet reviewed. Each says so at its top. ### Modality Page: /language-literacy/modality > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** Which ways of communicating (text, voice, voice notes, video) does the audience prefer and use comfortably? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out how the intended users prefer to communicate, and which ways they can use with ease: typed text, voice calls, voice notes, images or video. Ask, too, where they get information today and through which channels, such as WhatsApp, radio or a trusted person [src-028 p23; src-027 pp34-35]. The answers differ between countries and within them, by town and countryside, gender, class and ethnic group [src-006 p14]. Voice channels work on basic phones and suit people who cannot read or are uneasy with text [src-038 p17]. Some people prefer to get information from a person rather than a tool [src-028 p23]. #### Why it matters for AI tools Most language models have been built for typed text in widely written languages. Speech models now make voice-first tools more feasible, but many low-resource languages are mainly spoken and remain poorly covered [src-015 p38]. A text chatbot can therefore shut out people who read little or speak a language rarely written down. The Digital Futures Lab playbook advises voice-based navigation, with spoken questions and audio answers, for users with low literacy or physical disabilities. Even for literate users, it suggests mixing text with images, voice notes or video [src-028 p47]. Text can also be hard for reasons other than literacy, such as poor eyesight [src-004 p13]. And some people trust in-person contact far more than any phone channel: Plan staff in Senegal found that phones saved time, but local culture responded much more to physical presence [src-039 p85]. Users may also use a service differently from its design. When Plan Benin launched an SMS line for reporting violence against children, many people phoned or asked for a call back instead of texting. The team thought this might reflect literacy, habit from other helplines, or an expectation of a live person [src-039 p87]. A tool built around one mode may miss how people actually reach out. Modality also affects cost and device needs. Many AI tools run as smartphone apps; SMS or voice chatbots reduce that need, though SMS is costly in some countries [src-015 p37]. #### What good evidence looks like - Which modes users use now and are comfortable with, for each group (women and men, girls and boys, readers and non-readers) [src-039 pp37-38; src-038 p24]. - Where users get information today, and how an AI tool would fit with or disrupt those sources [src-028 p23]. - Whether the spoken word carries more weight than written material for the users [src-039 p36]. - Named apps or channels, if the project must choose one. In cognitive testing, many people did not tell SMS from WhatsApp messages, or ordinary calls from internet calls [src-020 pp28, 30-31]. - Whether users' phones have accessibility features such as text-to-speech or voice navigation [src-018 p18]. - A sample of real user questions in the modes users would choose. A PATH project with Nigerian community health workers gathered questions as text, voice, images and short videos [src-008 p11]. - A plan for more than one mode where users differ, for example voice and text options [src-031 p8; src-038 p24]. #### Red flags in a proposal - A text-only tool for users with low literacy or a mainly spoken language [src-038 p17; src-015 p38]. - The channel is chosen because it suits the developer, not because users already use it [src-028 p23; src-006 p38]. - No evidence on whether users would rather talk to a person [src-028 p23]. - Survey data on "messaging" is taken as evidence that users use a specific app [src-020 pp28, 30]. - A single channel for everyone, with no thought for differences by gender, place or literacy [src-006 p14; src-039 pp37-38]. #### How to find out Participatory tools such as a communication matrix, where each group lists the media they use for spoken, written, image and number-based communication, filled in separately by women, men, girls and boys [src-039 pp37-38]. A facilitated workshop where users list how they get and share information for each kind of need, such as emergencies, health or confidential reports [src-031 p2]. Communication resource mapping and Venn diagrams to show preferred channels and how information flows, including informal channels [src-027 pp34-35]. Survey questions on calls, voice messages and text messages, with app names where the choice of app matters [src-020 pp28, 30-31]. Collecting real questions from users in their own words and modes [src-008 p11]. Watching how people use a pilot service, since use can differ from plans [src-039 p87]. #### Limits and disagreements Most sources are about communication channels (radio, SMS, voice lines) rather than the modes of an AI tool. The SDC guide is from 2016 [src-006 p24], the World Bank guide from 2009 [src-027 p34], and the UNICEF paper from 2013 [src-038 p17]. Only three sources discuss AI [src-015 pp37-38; src-028 pp23, 47; src-008 p11]. None compares how users respond to voice and text versions of the same AI tool. Radio still matters in many places. The SDC guide notes that in remote rural areas radio is often the only medium and the main source of information [src-006 p24]. A Level 0 study may find that the best route is not a direct AI tool at all. Voice is not always safer. Girl Effect's safeguarding guide notes that for sensitive topics video may carry more risk than audio, and text more than audio [src-037 p18]. Teams should weigh safety as well as preference. #### Practitioner detail Informal channels often matter more than formal ones. In an Eastern Africa health project, villagers took up a new practice only once local healers, rather than city doctors, carried the message [src-027 pp34-35]. The EDiT skills guide allows voice search as well as typed search in its questions, for people with low literacy [src-020 p20]. Survey questions on voice messages and internet calls should not name a single app unless the project is choosing which app to build on [src-020 pp30-31]. #### Sources - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: pages 17, 24. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 36, 37, 38, 85, 87. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 37, 38. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 23, 47. - **src-020**: Measuring Digital Skills in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: pages 20, 28, 30, 31. - **src-018**: Measuring Digital Access in Low- and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2024. Cited: page 18. - **src-008**: Designing Trust: A step-by-step guide for applying Human-Centered Design principles in creating benchmarking datasets for training and testing large language models to be used in clinical decision support. PATH, 2025. Cited: page 11. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: pages 2, 8. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 18. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: pages 14, 24, 38. - **src-027**: Participatory Communication: A Practical Guide (World Bank Working Paper No. 170). The World Bank, 2009. Cited: pages 34, 35. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 13. ### Model performance Page: /language-literacy/model-performance > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** How well do the proposed language models perform in the audience's languages, code-switching and modalities? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Find out how well the AI models a project plans to use work in the users' own languages, in the way they mix languages, and in the modes they use, such as voice. Most language models work best in English and other widely written languages, and have mostly been used through typed text [src-015 p38]. Speech models are making voice tools more feasible, but many low-resource languages, often mainly spoken, are still poorly covered [src-015 p38]. A vendor's claim that a language is "supported" says little on its own. Ask for evidence of how quality differs between languages [src-011 p9]. #### Why it matters for AI tools A model that handles English well may fail its users in their own language. IREX gives an illustrative Kenyan example: a customer support chatbot treats messages in Swahili or Sheng (a mix of Swahili and English) as rule-breaking, so those users get more non-responses and account flags [src-013 p10]. Voice-to-text can miss a regional dialect, and the answer that follows is weaker for it [src-012 p17]. An answer can also be accurate but ignore the user's daily life and beliefs [src-012 p17]. Standard benchmarks do not settle the question. Most medical benchmark datasets come from high-resource settings and use structured, text-based exam questions [src-008 p9]. They miss the cases and languages of frontline health workers in Africa [src-008 p9]. NIST's AI risk playbook makes the general point: AI systems are brittle and do not carry over well outside the setting they were built in, so they need evaluating locally [src-024 p101]. A model's score on its own also says little about how people fare when they use it. In a UK experiment, models alone identified the condition in 95% of made-up medical cases, but members of the public using the models did so in only 35% [src-015 p19]. #### What good evidence looks like - Results from testing the shortlisted models on a small set of real examples from the users, including hard cases, with the same prompts for each model [src-007 p35]. - Test material in the users' languages, mixed-language styles and modes, not only English text. PATH's Nigerian benchmark used real questions in five languages, as text, voice, images and video [src-008 p11]. - Scores reviewed by both subject experts and members of the target group, for accuracy, fit and usefulness [src-028 p43]. - Testing with end users in conditions close to real use, compared with a human baseline. Machine errors can differ in kind from human ones [src-024 pp82, 84, 87]. - For a specialist domain, a panel of local experts. PATH's method collects answers from at least one local clinician and two or more models for each question, and has licensed clinicians from the region score them on a rubric that covers harm and understanding of local context [src-008 pp25, 37-39]. - Performance thresholds set before launch and shared with the funder [src-028 p43; src-012 pp23-24]. - Checks on cultural fit and tone as well as accuracy. Girl Effect's release tests covered safeguarding, reliability, accuracy and "resonance", meaning tone and cultural relevance [src-012 pp23-24]. - Evidence from the vendor on quality differences between the languages it supports [src-011 p9]. - Cost, speed and upkeep of each model, alongside quality [src-007 p35]. #### Red flags in a proposal - The proposal claims the model supports a language without test results in that language [src-011 p9]. - Performance evidence comes only from general benchmarks or English exam-style questions [src-008 p9]. - Testing covers text only, though users will speak or send voice notes [src-015 p38; src-012 p17]. - No test of mixed-language input, though users mix languages, as in Hinglish or Sheng [src-012 p11; src-013 p10]. - The model is judged only on its own scores, with no testing with real users [src-015 p19]. - No one from the target group reviews outputs [src-028 p43]. - The AI works through translation from English, with no check for bias added in translation [src-028 p26]. #### How to find out A small "golden dataset" (a reference set of real examples with agreed good answers) run across shortlisted models [src-007 p35]. A locally built benchmark from questions users or frontline workers send in their own words and languages. In Rwanda, community health workers recorded 5,600 cases by voice in Kinyarwanda; these were transcribed, translated and answered by local clinicians in both languages [src-008 p12]. Review of outputs by subject experts and the target group together [src-028 p43]. Another language model can help check outputs and lighten the load on reviewers, but it is not foolproof [src-028 p43]. Questions to vendors on language coverage and quality [src-011 p9]. #### Limits and disagreements No source in the corpus reports measured performance figures for a model in a specific low-resource language. PATH reports that its benchmark showed strengths and weaknesses across text, audio and images, without figures in this guide [src-008 p11]. The IREX Kenya case is illustrative and names no project [src-013 p10]. The evidence leans on health. Two of the eight sources are about clinical decision support [src-008 p9; src-015 p19], and the UK experiment is not from a low- or middle-income country [src-015 p19]. Sources differ on how far to rely on general AI. Girl Effect's three chatbots, serving South African English, Hinglish and Sheng, are built on fixed decision trees, with human agents answering questions. AI is limited to sorting messages, and only some users of one chatbot get generative answers, as part of a study [src-012 pp10-11]. Dalberg advises choosing the simplest model that reliably meets the need [src-007 p35]. A Level 0 study may conclude that a simpler design avoids the language problem. None of the sources reports a test of code-switching (moving between languages in one conversation). The Digital Futures Lab playbook advises training on mixed English and regional-language data, and notes that toxic-language detection can fail on code-switched input [src-028 p40]. #### Practitioner detail When choosing between models, measure accuracy, speed and cost per output, and have two reviewers rate quality and clarity. If the internet is unreliable, favour models that work offline or on slow connections [src-007 p35]. Count hosting, API fees, retraining and staff time [src-007 p35]. PATH's evaluation panel works in threes: two clinicians score each case independently, discuss large differences, and a more senior third member breaks ties. Evaluators should have three to five years of practice in the local health system and get a day's training [src-008 p40]. Teams should pick the rubric criteria that matter for their use, since a long rubric costs expert time [src-008 p37]. Translation adds its own bias. Digital Futures Lab's study of gender bias in language models lists, for farming chatbots in India, bias that enters translations from English into Indian languages and little research on the words women farmers use [src-028 p26]. Girl Effect's release metrics give an example set: precision and recall for spotting sensitive disclosures; latency and handling at least ten users at once; answer correctness and hallucination (confident but false output); and readability and tone for cultural fit [src-012 p24]. #### Sources - **src-008**: Designing Trust: A step-by-step guide for applying Human-Centered Design principles in creating benchmarking datasets for training and testing large language models to be used in clinical decision support. PATH, 2025. Cited: pages 9, 11, 12, 25, 37, 38, 39, 40. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: page 35. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: page 9. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 10, 11, 17, 23, 24. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: page 10. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 19, 38. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 26, 40, 43, 44. - **src-024**: AI RMF Playbook. Cited: pages 82, 84, 87, 101. ### Guidance for AI assistants 2 of 2 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E5 Competitor and actor landscape Questions in this bucket: - **E5.1 Similar initiatives.** Which local or international development organisations have built, or are building, a similar use case in the same context? - **E5.2 Content producers.** Which brands, influencers, government bodies or NGOs already produce content on the topic? What do they do well, and where are the gaps? > [!WARNING] > 1 of 1 pages in this bucket are not yet reviewed. Each says so at its top. ### Similar initiatives Page: /landscape/similar-initiatives > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. **Question:** Which local or international development organisations have built, or are building, a similar use case in the same context? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 #### Basics Find out who else has built, or is building, a tool for the same problem with the same kind of users in the same place. Look at local groups, international agencies, government and private firms, and at the applicant's own organisation [src-039 p13; src-004 p14]. Include other donors funding the same issue [src-006 p36], and government policies and sector strategies the tool should support [src-010 p3]. For each one, find out what they built, how it went and what they learned [src-037 p13; src-028 p23]. Then decide whether the new project should reuse, join, partner with or step back from that work, rather than start from nothing [src-010 p4; src-030 p37]. #### Why it matters for AI tools Health AI in Africa is a crowded field with little coordination. One guide on clinical language models describes funders, implementers and innovators working apart, which limits shared learning and leads to repeated effort [src-008 p5]. A large language model (LLM) is software trained on large amounts of text to answer questions in ordinary language. Without a look at similar work, a team may spend donor money building a chatbot that already exists nearby. A guide on ethical chatbots lists duplication of existing initiatives as a way to waste development resources [src-012 p21]. The Principles for Digital Development say that going it alone wastes resources, which matters more when the money is public, and puts extra burden on the people served [src-010 p4]. A landscape review also shows the pitfalls others have hit, so the team can plan around them [src-028 p23]. Public collections of AI incidents, such as the AI Incident Database and AIAAIC, record failures of deployed systems [src-024 p29]. A team that knows them can avoid repeating known failure modes [src-024 p44]. What a similar tool achieved matters more than how many people used it. In Kenya, over 85% of small business owners offered an AI business-advice chatbot on WhatsApp used it. A randomised evaluation found no average gain in profits or revenue, and owners who were earning less before ended up worse off [src-015 p10]. Results also travel badly. A chatbot that raised on-time college enrolment in one United States state had no overall effect in another, where most students enrolled anyway [src-015 p19]. AI decision support cut clinicians' errors in a chain of Kenyan clinics. In two Nigerian clinics, language model feedback to community health workers brought little or no gain in diagnosis or treatment, as judged by doctors on site [src-015 p23]. For AI tools, it can show whether a non-AI approach already works, and so whether AI is needed at all [src-025 p18]. #### What good evidence looks like - A list of similar tools and projects in the same country, sector and user group, with who runs each one and what it does [src-028 p23; src-039 p13]. - For each similar project, what happened: results, problems and lessons, not only its name [src-037 p13; src-028 p23]. - A search inside the applicant's own organisation, since past technology work is often not labelled as such and gets missed [src-039 p13; src-004 p10]. - A comparison of other AI approaches, with their strengths and weaknesses set side by side [src-025 p18]. - For each similar AI tool, the best evidence of its effect on users, with who produced it. A developer's own figures are weaker than an independent study [src-015 p19; src-024 p63]. - Known failures of similar systems, drawn from incident collections and past projects [src-024 pp29, 44]. - Other funders working on the same issue, and whether the project could join forces with them [src-006 p36]. - A clear statement of why existing tools, data or frameworks cannot be reused or adapted [src-030 p37; src-010 p4]. - Named partners found through the review, and what each will contribute [src-028 p25; src-039 p40]. - Notes from at least one conversation with someone who has built something similar, covering problems, upkeep and running costs [src-031 p9]. #### Red flags in a proposal - No mention of other tools or projects working on the same problem in the same place [src-012 p21; src-008 p14]. - The applicant plans to build something new without saying why existing tools will not do [src-030 p37; src-010 p4]. - Other initiatives are listed only as competitors to beat, with no thought of partnering or reuse [src-012 p21; src-039 p40]. - No question of whether the project could crowd out others who might solve the problem better or for longer [src-037 p13]. - The landscape review only looks for gaps that justify AI, and skips the question of whether AI is needed [src-025 p18]. - The team plans to build in-house a part that a specialist partner could deliver better [src-004 p14; src-028 p25]. - A similar tool's usage figures, or its developer's claims, are offered as proof that the approach works [src-015 pp10, 19]. - The review ignores national digital strategies and shared public systems the tool could build on [src-010 p3]. #### How to find out Desk research: search reports, project databases, blogs and network sites for similar tools in the same country and sector [src-012 p21; src-039 p40]. Blogs and networks are sometimes the only way to learn about projects still under way [src-039 p40]. Internal mapping: ask colleagues and country offices directly what technology work they have done, since it may not show up in reports [src-039 pp13, 22]. Stakeholder mapping: map technology providers, development projects and networks working in the area, with local partners or community volunteers [src-004 p14; src-039 p13]. Interviews with builders: talk to people who have built a similar tool about problems, costs, maintenance and sustainability [src-031 p9]. Case study review: collect case studies of other AI projects and compare their approaches in a simple table [src-025 p18]. Evidence and incident review: check published evaluations of similar tools, and check the scientific claims about their performance before design starts [src-024 p63]. Search AI incident collections for failures of comparable systems [src-024 p29]. These methods suit different budgets and stages. If none can be done during design, the budget should set aside time for it in the discovery phase [src-012 p21]. The landscape changes, so the review needs repeating as the project runs [src-010 p3]. #### Limits and disagreements The sources agree that teams should look before they build. They differ on why. - Some frame the review as competitor analysis [src-012 p21; src-028 p20]. Others frame it as finding collaborators and reusing what works [src-010 p4; src-039 p40]. A funder may want to see both. - NetHope's toolkit uses the review to show where existing systems fall short and where AI could add value [src-025 p18]. Girl Effect's safeguarding guide asks whether the project might get in the way of others with a better approach [src-037 p13]. The first can lead to a case for building; the second can lead to a decision not to build. - Digital Futures Lab treats landscape analysis as core to every AI project [src-028 p23]. Plan's guidance treats it as a step that runs through the whole project [src-039 p16]. Context limits: - Seven of the 13 sources are not about AI. They come from earlier ICT for development work (using phones, computers and the internet in aid programmes), much of it from Plan in East and West Africa [src-004 p14; src-039 p22]. The advice is general, but the examples predate AI tools. - The AI sources cover health in Africa [src-008 p5], India across several sectors [src-028 p23], chatbots for behaviour change [src-012 p21] and gender in humanitarian work [src-025 p18]. NIST's framework is written for United States organisations [src-024 p63]. None gives a worked example of a landscape review for an AI tool. - The outcome findings come from one evidence review by J-PAL, a research centre that runs randomised evaluations [src-015 pp10, 19, 23]. They show why results of similar tools matter, but each comes from one study in one country. - Four sources share MTI-linked authors (src-012, src-030, src-037, src-039). Their agreement is less independent than it looks. src-030 also restates the Principles for Digital Development (src-010), so those two are close to one voice [src-030 p35]. - Support is broad but shallow. Most sources give the instruction in a sentence or two. Only src-031 describes how to run one part of the review, and that is for an online course, not an AI tool [src-031 p9]. #### Practitioner detail A landscape review can feed the theory of change (a map of how activities lead to results). Digital Futures Lab lists competitor analysis among the first activities for a generative AI project [src-028 p20]. It also suggests a separate landscaping study to find partners who can help co-create, roll out and evaluate the tool [src-028 p25]. PATH's planning tool puts the question of related or benchmark projects in its first stage, next to defining the problem and the users [src-008 p14]. Plan's guidance treats learning from others as both the first and last step, and asks teams to share their own lessons for those who come after [src-039 p16]. Plan's country briefings give a model for the list itself. The Ghana briefing names national policy processes, a knowledge-sharing network, a public telecoms fund and local institutions working on technology [src-039 p60]. For each similar chatbot, record more than its name. Girl Effect sets out its three health chatbots, in South Africa, India and Kenya, in one table. It records the language each serves, how each uses AI, and where human agents step in. All three rest on fixed decision trees. Two use AI to sort user questions; the Kenyan one uses keyword matching and had no AI at the time of writing [src-012 pp10-11]. #### Sources - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 10, 14. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 13, 16, 22, 40, 60. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 10, 11, 21. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 13. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 35, 37. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: page 9. - **src-008**: Designing Trust: A step-by-step guide for applying Human-Centered Design principles in creating benchmarking datasets for training and testing large language models to be used in clinical decision support. PATH, 2025. Cited: pages 5, 14. - **src-010**: Principles for Digital Development. Digital Impact Alliance (DIAL), 2024. Cited: pages 3, 4. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: page 18. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 20, 23, 25. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: page 36. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 10, 19, 23. - **src-024**: AI RMF Playbook. Cited: pages 29, 44, 63. ### Guidance for AI assistants 1 of 1 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E7 Risk, safety and safeguarding Items not yet agreed. Pages here are candidate items. > [!WARNING] > 2 of 2 pages in this bucket are not yet reviewed. Each says so at its top. ### Bias and fairness Page: /risk-safety/bias-and-fairness > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Will the tool work as well, and as safely, for women, poorer, older, rural and minority-language users as for others, and how will the team find out? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 #### Basics Bias, here, means an AI tool treats some groups worse than others in a systematic way, often with no one intending it [src-024 p126]. Level 0 work should find out which groups the tool may serve badly, such as women, poorer, older, rural, disabled or minority-language users, and why [src-001 p6; src-035 p13]. It should also say how the team will check performance for each of those groups, not only on average [src-024 p105]. A tool can be popular and cheap to run and still leave some groups further behind [src-030 p31]. #### Why it matters for AI tools - Models learn from data. Programme data already carries social inequality, and much training data comes from institutions in the global North, so a model can start from a skewed base [src-025 p9]. - People who leave few digital records are easy for a model to miss. This includes informal workers, rural families, people who read little and speakers of minority languages [src-015 p38]. - Women are less likely to have mobile money histories or bills in their own name. Credit models built on such data can shut them out without anyone meaning to [src-015 p38]. - Language models tend to work best in English and other well-digitised languages [src-015 p38]. IREX gives a hypothetical example: a Kenyan support chatbot that treats messages in Swahili or Sheng as breaking its rules, so those users get ignored or flagged more often [src-013 p10]. - Generative AI can give different advice for the same facts depending on gender. In one reported test, a chatbot offered women meal planning and men estate planning [src-036 p2]. In another, a model judged a male student more confidently than a female student with the same record [src-029 p21]. - In farming advice, AI may fit men's crops and practices better, and serve people marginalised by caste, age, ethnicity or disability less well [src-003 pp9, 12; src-028 p26]. - Choosing who gets help by predicted benefit, rather than need, can move support away from the poorest [src-015 p14]. #### What good evidence looks like - The proposal names the groups most likely to be served badly in this setting, and explains why for each [src-001 pp4, 6; src-035 p13]. - It describes who is represented in the training or reference data, and where the gaps are for the target users [src-007 p7; src-028 p26]. - It plans to report test results broken down by gender, age, region, disability and language, not as one overall score [src-024 pp105, 127]. - Testing includes people from the groups at risk, not only staff or experts [src-007 p7; src-024 p127]. - It shows what the vendor's bias testing covers, which groups it checked, and how that compares with the users the project will reach [src-011 p10]. - It treats exclusion as a harm in its own right, and says how it will reach groups the digital channel leaves out, for example through face-to-face contact [src-030 p32]. - Each group in the test has enough cases to show a real difference; a handful of answers per group proves little [src-025 p30]. - It says in advance how large a gap between groups is acceptable, and what the team will do if a gap goes beyond it, up to withdrawing the model [src-024 p128; src-025 p33]. - It allows for fairness meaning different things in different cultures, and agrees with affected communities what counts as fair [src-024 pp126-127]. #### Red flags in a proposal - No mention of which groups the tool might serve worse [src-001 p4]. - Only an average accuracy or satisfaction figure, with no breakdown by group [src-024 p105]. - A plan to detect bias through user surveys alone [src-019 pp9, 12]. - Reliance on a grievance or complaints channel as the main safeguard, with no checks before launch [src-035 p13]. - A tool built on mobile phone, mobile money or other digital records, with no plan for people who leave few such records [src-015 pp38, 44]. - Translation from English into local languages with no check for bias added in translation [src-028 p26]. - A third-party model with no information on how its maker tested for bias [src-011 p10]. - Profiling or personalising content for users without telling them first or letting them refuse [src-037 p21]. - A claim that the AI tool will reduce human bias, with no plan to test it. Evidence that algorithms reduce bias in real decisions is still thin [src-015 p31]. #### How to find out Several routes exist, and each sees different things. Analysis of large sets of AI outputs and their metadata can show patterns no single user notices [src-019 pp9, 12]. Expert review of outputs can check them for fairness, accuracy and harmful patterns [src-019 p12]. Paired prompt tests, where one detail such as gender or name changes and everything else stays the same, are simple to run and show differences directly [src-029 pp20-21]. Breaking evaluation results down by group, with fairness measures chosen for the setting, shows who the tool serves less well [src-024 pp126-127]. Asking vendors detailed questions about their testing covers models the team did not build [src-011 p10]. Talking with potential users, community members and people from at-risk groups shows barriers of language, literacy, connectivity and device access that outputs alone will not reveal [src-007 p7; src-024 p127]. Comparing digital data against household surveys shows who digital records miss [src-015 p44]. A gender impact assessment asks whether a programme serves the differing needs of each gender group, including women, men and gender-diverse people. Pollicy, drawing on the Equality Institute, sets out four steps: define the issue, understand the context, compare options, and recommend. It adds attention to overlapping disadvantage and asks for the check to be repeated through design and adoption, not done once [src-035 pp15-16]. NetHope asks for a similar impact assessment at the problem stage, covering who can reach the digital service and who takes part in design, and for an ethics committee of at least three people covering AI, programme work and data privacy [src-025 p18]. #### Limits and disagreements - **Surveys versus other routes.** The EDiT guide says surveys of users cannot measure AI bias well, because users rarely see it [src-019 pp9, 12]. SIMLab and Dalberg still treat user participation and questions about exclusion as part of the check [src-030 p32; src-007 p7]. Surveys can show who is left out, but not how the model behaves. The EDiT point rests on one family. - **Accuracy and cost.** J-PAL reports that survey-based targeting usually finds poor households more accurately than machine learning, which can be cheaper at national scale [src-015 p14]. In Togo, machine learning targeting worked fast without a social registry and did not systematically exclude ethnic or religious groups [src-015 p15]. Yet phone data alone gave misleading estimates of the programme's effects [src-015 p44]. A model can be fair on one test and still miss people. - **Balance is not fairness.** NIST notes that a system with similar results across groups can still exclude disabled people or those with poor connectivity [src-024 p126]. - **Same answer or tailored answer.** The paired prompt tests treat different advice by gender as a fault [src-036 p2; src-029 p21]. Digital Futures Lab notes that a tool may be designed on purpose to answer some groups differently, for example by telling low-income women about schemes meant for them [src-028 p40]. A proposal should say which it intends and why. - **Reactive or proactive.** Pollicy argues that grievance channels are not enough and asks for more representative data and teams [src-035 p13]. Other sources do not take a position on this. - **Where the examples come from.** Many cases are from the United States or global products, reported second-hand without method details: a recruiting tool, translation, voice assistants, CV screening and the ChatGPT finance test [src-025 p7; src-013 p6; src-036 p2]. The NetHope source gives no references for its three examples [src-025 p7]. Real cases from low- and middle-income countries are few: Togo [src-015 p15] and India's farmers [src-028 p26]. The Kenyan chatbot example is illustrative, not a reported case [src-013 p10]. - **Who tested.** UNESCO's paired prompt test was run with senior diplomats and UNESCO staff, not a target community [src-029 p9]. - **Age of sources.** SIMLab and Girl Effect date from 2018, before generative AI, and Girl Effect writes from EU data law [src-030 p31; src-037 p21]. NIST is a United States framework [src-024 p126]. - **Shared voices.** NetHope supplies two sources [src-011 p10; src-025 p9]. SIMLab and Girl Effect share MTI-linked authors, so their agreement is less independent than it looks. #### Practitioner detail NIST names three kinds of bias. Systemic bias sits in data, organisations and society. Computational and statistical bias often comes from samples that do not match the population. Human-cognitive bias concerns how people read and act on AI output [src-024 p126]. NIST also suggests looking for input features that stand in for group membership, such as postcode, and testing within and across intersecting groups [src-024 p127]. For data, NetHope's interviewees point to clear labelling rules and annotators from varied backgrounds [src-025 p9]. Digital Futures Lab adds that annotators' own backgrounds shape what they mark as harmful [src-028 p26]. #### Sources - **src-001**: Decision Tree for the Responsible Application of Artificial Intelligence (v1.0). AAAS Center for Scientific Responsibility and Justice (CSRJ). Cited: pages 4, 6. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: pages 9, 12. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: page 7. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: page 10. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: pages 6, 10. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 14, 15, 31, 38, 44. - **src-019**: Measuring Digital Harms in Low and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2025. Cited: pages 9, 12. - **src-024**: AI RMF Playbook. Cited: pages 105, 126, 127, 128. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: pages 7, 9, 18, 30, 33. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 8, 26, 40. - **src-029**: Red Teaming Artificial Intelligence for Social Good: The Playbook. UNESCO, 2025. Cited: pages 9, 20, 21. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 31, 32. - **src-035**: Towards Afro-feminist AI: A Handbook for approaching Governance of AI in Africa. Cited: pages 13, 15, 16. - **src-036**: Strive Women Playbook. CARE (Strive Women, part of Mastercard Strive), 2026. Cited: page 2. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 21. ### Harm scenarios and risk assessment Page: /risk-safety/harm-and-risk > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** What could go wrong for users and others if the tool is built, how likely and severe is each harm, and how will the team prevent and respond to it? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 #### Basics Before an AI tool is built, the team should write down how it could hurt the people who use it and the people around them. For each harm, they should judge how likely it is and how bad it would be, then decide what they will do to prevent it and how they will respond if it happens anyway [src-014 p35; src-013 p15; src-037 p26]. Harms can be direct or indirect, and intended or accidental [src-019 p11]. They include false or unsafe advice, privacy breaches, fraud, violence enabled by technology, and effects on physical and mental health [src-019 pp11-12; src-013 p11]. #### Why it matters for AI tools AI makes some old harms larger and faster. It can produce abusive content and deepfakes at volume, and its workings are hard to inspect, which makes safety checks difficult [src-014 p66; src-029 p13]. Some harm comes from people misusing a tool on purpose; some comes from a tool behaving badly when used as intended [src-029 pp12-13]. Guardrails, the built-in limits meant to stop harmful output, are easy to get round. In a UNESCO test, calling a request fiction was enough to get a model to write insults about a named woman journalist in several languages, ready for a fake harassment campaign [src-029 pp22-23]. Even a very accurate system can cause harm, and a widely used tool will be put to uses its builders never planned [src-024 p62]. Unplanned use is documented. In Turkey, students given a basic chatbot scored worse in exams than students with no chatbot, while a version with learning safeguards avoided this [src-015 p39]. After one organisation scaled its AI tool, frontline staff began treating it as the decision-maker and gave less personal support [src-028 p58]. Remote contact carries its own risk, even without AI. A Ukrainian health service for adolescent female sex workers flagged that giving test results by phone could lead them to treat themselves and skip clinic visits [src-038 p23]. People in crisis use chatbots for help the bot was never built to give. Many quickly built health chatbots could not recognise a message about violence or self-harm and offered no route to a human [src-034 p3]. Harm can also arise in the wider system. A woman who cited a legal chatbot at a police station was turned away, because the project had engaged women users but not the police [src-028 p22]. DIAL notes that harms from AI are less well understood than harms from other technology [src-010 p10]. A review of harms to health workers in low- and middle-income countries found only two studies that looked at AI at all [src-017 p5]. Little evidence of harm does not mean little harm. Bias and unfair treatment of groups is covered on its own page in this bucket. #### What good evidence looks like - A list of harms for each user group, including bystanders and people affected by the tool but not using it [src-014 p35; src-024 p83]. - At the idea stage, before design, the team asked whether the core idea could be turned against its users and whether the business model works against user safety [src-014 pp40, 42]. - Both accidental harms and deliberate misuse are considered, with examples specific to the tool [src-029 pp12-13; src-014 p35]. - Each harm is scored for likelihood and severity, mitigations are named, and the leftover risk is scored again [src-014 p35; src-037 p58; src-024 p9]. - Low-scored risks still have a planned response; scoring sets the order of work, not what to ignore [src-014 p45]. - Users, especially vulnerable ones, helped name the risks, and their concerns carry weight in setting priorities [src-012 p21; src-038 p26; src-013 p15]. - A named person owns each mitigation, with a deadline and sign-off [src-037 pp26-27]. - A clear point at which the team will halt or not launch [src-037 p58; src-024 p71]. - The risks of the AI tool are compared with those of a simpler model, a manual process or human staff doing the same job [src-024 p135]. - A person checks outputs before they affect anyone, and that person can overrule the tool [src-011 p9; src-013 p15]. - A plan for people who disclose danger to the tool, with a route to human help [src-034 pp3-4]. - A date and trigger for repeating the assessment, such as new features or a change in context [src-037 p27; src-003 p5]. #### Red flags in a proposal - Risks are listed only as accuracy or uptake problems, with no harm to people named [src-003 p5]. - Only the main user group is considered, not others affected [src-014 p35; src-024 p83]. - No one asks whether use is truly optional for the people affected [src-035 p12]. - No statement of who owns the implementer or what else the data will be used for [src-035 p17]. - An open-ended chatbot faces the public with no plan for how its wide range of risks will be managed [src-024 p85]. - Advice on health or money with no human check before anyone acts on it [src-013 p11; src-015 p45]. - The risk assessment is a one-off form with no plan to revisit it [src-037 p27; src-028 p23]. - A tool is added on top of existing paper or digital systems without asking what extra work it creates [src-017 pp5-6]. - The tool rests on a pre-trained model from another company, and there is no plan to track that model's risks. Such models make bad outcomes harder to foresee and to trace [src-024 p55]. #### How to find out Several methods can surface harms, and each misses some things. Ready-made lists help a team start. Girl Effect sets out twelve risk areas for behaviour change chatbots, such as loss of human contact, drained phone data, wrong or toxic replies, environmental cost and poorly paid data workers, and marks which ones generative AI makes worse [src-012 pp15-17]. It also notes that many are old problems in a new form, so existing safeguarding practice still applies [src-012 p17]. IREX lists risks by type of technology. For chatbots these include over-reliance, weaker critical thinking, tracking without consent and leaks of behavioural data; for data collection apps, leaks, consent failures and poor data on groups already left out [src-014 pp12-13]. For tools aimed at health workers, the EDiT framework links each area of digital work to harms such as false information, constant monitoring, duplicate paper and digital systems, loss of skills and out-of-pocket costs, and then to effects on patients, staff and the health system [src-017 p1]. To describe a single harm in full, EDiT suggests recording who was involved, the type, how often and how severe it was, the channel, how the person responded, and the impact, for example physical, psychological, economic or reputational. Social norms shape each step [src-019 p14]. The kind of device access people have, such as a shared phone, also shapes their exposure, so ask about it first [src-019 p21]. A participatory stakeholder analysis brings users, staff and community leaders together to name local dangers. In one Indian example, it showed that a phone line to mostly female staff could be abused, and the team switched to in-person feedback [src-031 p2]. Social risk questions ask whether using the tool could change how users are seen, or expose children or homes through location data [src-004 p13]. A futures wheel maps the direct and knock-on effects of a decision with domain experts [src-028 pp23-24]. Searching for similar cases where automated decisions failed shows what has gone wrong elsewhere [src-001 p4; src-024 p93]. Structured lists of failure points, such as a nine-stage taxonomy for farm advice, help a team check where a tool could break down, even when the model is accurate [src-003 p3]. Red-teaming means testing the tool or concept by trying to make it cause harm [src-013 p15]. A risk register records each harm, its scores, its controls and its owner [src-014 p35; src-037 p58]. One register built for chatbots is PRIMA, IREX's Predictive Risk and Mitigation Audit. It asks about the tool's function, design and audience, flags privacy, safety and security risks with their likelihood, and suggests safety features; the tool itself is not in the source [src-013 p15]. Australia's eSafety Commissioner publishes free safety-by-design assessment tools, developed with industry, NGOs and users [src-014 pp27, 35]. #### Limits and disagreements Sources disagree on what to do when a risk cannot be estimated. Pollicy says an AI solution should not be deployed until likelihood and severity can be judged [src-035 pp10, 14]. AAAS asks for measures to reduce an uncertain risk unless it can be shown to be negligible, which allows going ahead [src-001 p6]. Digital Futures Lab accepts that some risks will only appear during a pilot [src-028 p23]. There is a tension on scope. NIST says a narrow, scripted chatbot is easier to manage than an open-ended one [src-024 p85]. UNICEF found that scripted health bots failed users in crisis because they could not recognise unexpected messages [src-034 p3]. Context limits: - NIST is a US government body writing for US organisations [src-024 p1]. - Pollicy's likelihood and severity table is aimed at state regulators in Africa, not project teams [src-035 p10]. - Girl Effect's assessment follows UK data protection guidance [src-037 p26]. - The health worker review covers mostly non-AI tools [src-017 p5]. Two thirds of its 99 studies looked at doctors, although community health workers are often the main users of digital tools. Most studies also measured end results such as burnout, not the harms that led to them [src-017 p3]. The review asks future work to cover frontline staff and AI, and to use tested survey tools [src-017 p6]. - AAAS describes the EU AI Act as a proposal, so its summary predates the law [src-001 p5]. - The UNICEF girls' guidance dates from 2013 [src-038 p25]. - Several cases come from India, Pakistan and Turkey, often without the organisation being named [src-028 pp22, 58; src-015 p39]. - Proving that a tool caused a health harm needs a purpose-built study; a general survey will not show it [src-019 pp46-47]. Shared authors: src-012, src-034, src-037 and src-038 share MTI-linked authors, so their agreement on user involvement and safeguarding counts as less independent. The EDiT consortium (src-017, src-019) is one voice, and so is IREX (src-013, src-014). #### Practitioner detail Pollicy suggests matching the response to the score. For likely and severe harm, do not deploy until it is fixed. For unlikely but severe harm, commission an external human rights impact assessment. For likely but minor harm, offer strong redress for each person affected [src-035 p10]. Digital Green's taxonomy flags which risks fall hardest on women and which are specific to AI, and advises putting severe and inequitable risks first [src-003 pp3, 5]. The Girl Effect form scores severity and likelihood from 1 to 3 and stops the activity if the risk stays high after mitigation [src-037 p58]. Pollicy also lists questions that raise the level of scrutiny a tool needs. Is the person using the tool in a very different position from the person it affects? Does it predict human behaviour? Does it use personal data, even anonymised? Is a private company involved? Can a human reviewer check its decisions afterwards from information about the model and data? Pollicy wrote these for regulators [src-035 p11]. AAAS suggests where to start. Risk cannot be removed, so it must be ranked, and tools that deal with people directly or learn from large sensitive datasets come first [src-001 p5]. If a tool could involve emergency limits on people's rights, its decision tree asks whether the limits are needed at all, whether those affected know and agree, whether the limits are proportionate and time-bound, and whether affected people have a voice in oversight [src-001 p4]. #### Sources - **src-001**: Decision Tree for the Responsible Application of Artificial Intelligence (v1.0). AAAS Center for Scientific Responsibility and Justice (CSRJ). Cited: pages 4, 5, 6. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: pages 3, 5. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 13. - **src-010**: Principles for Digital Development. Digital Impact Alliance (DIAL), 2024. Cited: page 10. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: page 9. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 15, 16, 17, 21. - **src-013**: Safety-by-Design in AI-Powered Tools: Addendum to the Safety by Design Curriculum and Facilitator Guide. IREX, 2026. Cited: pages 11, 15. - **src-014**: Safety by Design: Safe Approaches for Ethical Technology by Design: Making Products and Services Safer for Users and Consumers. Curriculum and Facilitator Guide. IREX, 2025. Cited: pages 12, 13, 27, 35, 40, 42, 45, 66. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 39, 45. - **src-017**: Measurement of Harms Associated with Technology use among Health Workers. EDiT Consortium. Cited: pages 1, 3, 5, 6. - **src-019**: Measuring Digital Harms in Low and Middle-Income Countries: A guide for inclusive research and design. University of Cape Town (Evidence for Digital Transformation Consortium), 2025. Cited: pages 11, 12, 14, 21, 46, 47. - **src-024**: AI RMF Playbook. Cited: pages 1, 9, 55, 62, 71, 83, 85, 93, 135. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 22, 23, 24, 58. - **src-029**: Red Teaming Artificial Intelligence for Social Good: The Playbook. UNESCO, 2025. Cited: pages 12, 13, 22, 23. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: page 2. - **src-034**: Safer Chatbots Implementation Guide. UNICEF East Asia and Pacific Regional Office (Gender section). Cited: pages 3, 4. - **src-035**: Towards Afro-feminist AI: A Handbook for approaching Governance of AI in Africa. Cited: pages 10, 11, 12, 14, 17. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: pages 26, 27, 58. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: pages 23, 25, 26. ### Guidance for AI assistants 2 of 2 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E8 Problem definition and AI alternatives Items not yet agreed. Pages here are candidate items. > [!WARNING] > 2 of 2 pages in this bucket are not yet reviewed. Each says so at its top. ### Non-AI alternatives Page: /problem-alternatives/non-ai-alternatives > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Would a simpler, non-AI or non-digital option meet the need as well, and why is AI the better choice here? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Before funding an AI tool, find out what else could meet the same need. Options include changing how work is done, a basic digital tool, more training, more staff, a policy change, or doing nothing new [src-007 p18; src-015 p43]. A team should list these options with the benefits, limits and risks of each, and say with evidence why AI does better [src-001 p1]. If it cannot, the project may work as well or better without AI [src-004 p16; src-012 p22]. The separate page on problem definition covers how to state the problem itself. #### Why it matters for AI tools AI added where it does not fit can waste time, bring new risks and make services more fragile, and low-resource settings feel this most [src-007 p18]. Many AI tools need digital and AI literacy that poorer and marginalised groups may lack, so the people with most need may be the least able to use them [src-028 p15]. AI tools also cost more to keep running than fixed content such as standard text messages, because models, data and user behaviour change and the system needs updating [src-015 p44]. Where a tool scores or models people, as in credit scoring, the case for it should be strongest, including a reason why no reasonable alternative exists [src-035 p12]. Interest from donors or the media in new technology can push a programme towards tools that do not suit its users [src-038 p24]. A simpler digital tool may be enough. In early childhood education, structured digital support for teachers improved their practice and children's learning without any advanced AI features [src-015 p22]. #### What good evidence looks like - The proposal lists several ways to solve the problem, including a no-technology option, with the benefits, limits and risks of each [src-001 p1; src-030 p6]. - It names measures showing AI beats the other options, not only that AI can do the task [src-001 p1; src-015 p44]. - It describes how the problem is handled today and what the current process or tool fails to do [src-025 p18; src-030 p29]. - It states what the team would do without AI, such as a simple decision rule or more staff [src-015 p43]. - It counts the full cost of each option: data, dealings with mobile operators, upgrades, total cost of ownership and time spent supporting users [src-030 p30]. - It shows whether adding features to an existing tool would be cheaper than building a new one [src-030 p30]. - It shows that the people who need the service have the devices and skills the AI option assumes, or explains how others will be reached [src-028 pp15, 18]. - It shows the AI part supports existing workers or services rather than replacing them, or gives reasons where it replaces them [src-015 p21; src-039 p29]. - It records which other approaches the team weighed, as part of the project's standard documentation [src-024 p11]. - It describes a low-tech version of the service, such as a feature phone or human route, that users can fall back on [src-012 p24]. #### Red flags in a proposal - AI is chosen before other options are compared [src-001 p1; src-007 p18]. - The case for AI rests on what the technology can do, with no comparison against the current way of working [src-030 p29]. - The proposal assumes target users will soon own smartphones without evidence on cost, literacy, power or airtime [src-032 p10]. - A tool that scores or ranks people gives no reason why a traditional method would not do [src-035 p12]. - The budget covers building but not upkeep, updates or user support [src-015 p44; src-030 p30]. - AI replaces a human role, such as coaching, where trust and feedback matter, with no evidence it works as well [src-015 p21]. #### How to find out Map existing services and what already works for the target group, then ask which parts could move to a digital channel [src-016 p3; src-028 p13]. Run a stop-and-review point after the context work and before choosing any technology: ask whether the technology will help meet the goals, save time or money, do new or better things, or increase equity [src-004 p16]. Test each problem against a set of conditions for AI fit with a mixed group of staff, including frontline workers [src-007 p18]. Use a decision tree that sends the team back to other options when it cannot say how AI is better [src-001 p1]. Compare costs, using cost-benefit or cost-effectiveness analysis to set a technology route beside a traditional one [src-030 p44]. Ask whose job it is to fill a service gap, since advocacy may suit better than a new service [src-039 p29]. Plan to pilot the AI tool against a non-AI option before scaling [src-015 p20]. One trial of an AI career guidance tool in Kenya compares three arms: AI alone, human counsellors alone, and the two together [src-015 p24]. #### Limits and disagreements Support is broad: the core point appears across about a dozen publisher families. Most of these sources, though, are toolkits that state the principle rather than test it. Only J-PAL reports trial evidence, and its findings come from specific settings: teacher coaching in South Africa and labour courts in Mexico [src-015 pp21, 44]. J-PAL also shows AI can add value, but sometimes only when the process around it is right [src-015 p44]. Seven of the fifteen sources do not discuss AI at all; they speak about ICT (information and communication technology) in general [src-004 p16; src-006 p39; src-030 p6; src-038 p28]. Their lessons carry over, but they were not written about AI. SDC records an earlier cycle of hope: after the world summits on the information society in 2003 and 2005, early enthusiasm for mobile phones and the internet gave way to a more sober view. It concludes that technical, economic, political and cultural limits apply, and that ICT helps but cannot solve every development problem [src-006 p29]. Claims about AI deserve the same caution. Sources differ on how high to set the bar. Pollicy asks for the strongest proof only where tools model human behaviour and asks less of tools that model crops or weather [src-035 p12]. NIST treats non-AI options as part of routine risk work for any AI system [src-024 pp38, 43]. NIST writes from a United States risk management setting [src-024 p38]. Several sources share MTI-linked authors (src-012, src-030, src-038, src-039), so their agreement is less independent than it looks. Plan Finland supplies two sources (src-004, src-039) and SIMLab two (src-030, src-032). #### Practitioner detail NIST describes non-AI options as including semi-automated or mostly manual ways of gathering and judging information, and asks teams to weigh them during context mapping and again when choosing how to respond to risks [src-024 pp43, 62-63]. Once a system runs, NIST suggests setting its risks beside those of a simpler or traditional model, of human performance, and of other manual benchmarks [src-024 p135]. Cost-effectiveness analysis compares the cost of two or more routes to the same countable outcome, without putting a money value on that outcome [src-030 p44]. SDC asks, before producing a video or brochure, how many people will use it, how it will reach them, and whether a cheaper means would do [src-006 pp25, 39]. SDC does not apply this to digital tools; the same questions fit them. Girl Effect suggests starting AI on one small part of the user journey, such as onboarding, rather than the most obvious or exciting part [src-012 p24]. UNICEF advises combining new channels with radio, print and face-to-face outreach where access is uneven [src-038 p24]. #### Sources - **src-001**: Decision Tree for the Responsible Application of Artificial Intelligence (v1.0). AAAS Center for Scientific Responsibility and Justice (CSRJ). Cited: page 1. - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: page 16. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: pages 25, 29, 39. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: page 18. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 22, 24. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 20, 21, 22, 24, 43, 44. - **src-016**: Gender Formative BIG Research questions. Cited: page 3. - **src-024**: AI RMF Playbook. Cited: pages 11, 38, 43, 62, 63, 135. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: page 18. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 13, 15, 18. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 6, 29, 30, 44. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: page 10. - **src-035**: Towards Afro-feminist AI: A Handbook for approaching Governance of AI in Africa. Cited: page 12. - **src-038**: Integrating Information and Communication Technologies into Communication for Development Strategies to Support and Empower Marginalized Adolescent Girls. UNICEF (C4D Section, Programme Division), 2013. Cited: pages 24, 28. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: page 29. ### Problem definition Page: /problem-alternatives/problem-definition > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Is the problem clearly defined, with and by the people who have it, before any solution is chosen? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-23 #### Basics Before anyone picks a tool, the team should be able to say what problem it is solving, for whom, and how they know. The problem should be one specific, observable difficulty in people's lives or work, not a broad aim such as "better health" [src-007 p14; src-028 p14]. The people who live with the problem should have helped name it, and should recognise the description [src-007 p14; src-027 p36; src-037 p13]. Only once the problem is clear does it make sense to ask whether AI, or any technology, has a part in solving it [src-007 pp6, 10; src-039 p45; src-004 p10]. #### Why it matters for AI tools How a problem is framed decides which solution looks right. A team that frames a problem as missing information will build an information tool, even when the real cause is social, economic or about unequal power [src-027 p18]. Many AI tools in development deliver tailored information, so they are open to this trap [src-015 p16]. Information only changes behaviour when it fixes a real gap in what people believe and removes the barrier that stops them acting. In Rwanda, girls already overestimated HIV risk, so researchers advised against scaling an information programme that had cut teenage pregnancy in Kenya [src-015 p16]. A personalised AI messaging tool built on the wrong problem will not help, however well it performs. Vague problems also make AI risks hard to see. A narrow, well-defined task makes the benefits and harms of an AI system simpler to trace [src-024 p74; src-028 p14]. And a clear problem statement lets the team check whether the tool is worth building at all [src-024 p63]. A separate page covers non-AI alternatives: whether something other than AI could solve the same problem [src-012 p22; src-024 p63]. #### What good evidence looks like - A short problem statement naming who is affected, where the difficulty arises, what people do now to cope and what that costs them [src-007 p14]. Dalberg's template keeps it to one or two sentences, based on what users said rather than on the team's assumptions [src-007 p15]. - The problem statement has been tested with people who face the problem, and they recognise it [src-007 p14]. - The problem was explored openly with communities before objectives were fixed, not only checked against goals already set by the funder or implementer [src-027 p32; src-039 p27]. - Evidence that the intended users see this as a problem, and that local actors are involved in driving the work [src-037 p13]. - An analysis of root causes, not only symptoms, for example by repeatedly asking why the problem happens [src-025 p37; src-027 p36]. - What the audience already knows and believes, so the team can tell whether lack of information is really the barrier [src-015 p16; src-006 p74]. - A focus on one problem, or a closely related set, rather than many at once [src-028 p14; src-006 p38]. - A theory of change (a stated chain from activities to results, with the assumptions behind each link) that names the problem, what the AI will do, and what must be true for people to reach and use it [src-015 p7; src-030 pp10-11; src-004 pp27-28]. - Stakeholders, including less powerful groups, agree on the changes the project seeks [src-030 pp10-11]. #### Red flags in a proposal - The proposal starts with the technology and looks for a use for it [src-039 p45; src-037 p13; src-004 p10]. - The problem is described in broad terms that could fit hundreds of situations [src-007 p14]. - The target group is "the general public" or another audience too wide to reach [src-006 p37]. - Labels for the target group, such as "the poor", have not been checked with the people being labelled [src-027 p36]. - The community is treated as one group with one view of the problem, with no account of differences in power, wealth or opinion within it [src-027 p27]. - Lack of information is assumed to be the cause, with no evidence that it is [src-027 p18; src-015 p16]. - AI sits at the centre of the theory of change before the organisation has tested it on a smaller scale [src-012 p22]. - The problem was defined by outside experts with no record of local input [src-027 p31; src-039 p27]. - No logic model or theory of change, on the grounds that the funder did not ask for one [src-030 p12]. #### How to find out Several methods can help, and the right mix depends on the setting. Desk research and interviews with subject experts build an early picture [src-028 p14]. Survey data can show how widespread the problem is, and qualitative research can explain why it happens and who holds decision-making power [src-028 p14]. Participatory assessment opens a conversation with communities about their own priorities before objectives are set [src-027 pp31-32]. Working sessions with users and others in the system can turn many views into one problem statement [src-007 p14]. Mapping a theory of change, and marking where information and communication flows matter, shows where a tool might fit [src-004 pp27-28; src-030 p11]. Root-cause questioning with field teams can show which problems several programmes share [src-025 p37]. Context mapping looks at the setting, users, possible harms and cultural norms, ideally in or close to the real setting and with community groups [src-024 pp62-63]. No checklist on its own will diagnose the right technology; these methods are ways to test the team's assumptions [src-032 p6]. #### Limits and disagreements **Needs first or tools first.** Most sources say to start from the problem. Plan Finland names a real tension: setting goals too tightly around known tools can shut out useful innovation, so ideas from what technology makes possible still have a place [src-039 p27]. NetHope goes further the other way: it suggests matching field problems to models the organisation already has [src-025 p37]. That approach risks a solution looking for a problem, which Girl Effect warns against [src-037 p13]. **How much participation.** The World Bank guide sees full participation in defining the problem as the ideal, and treats an assessment that starts from fixed objectives as only partly participatory [src-027 p32]. The AI-focused sources describe involvement as working sessions with users or collaboration with community groups, and leave open who sets the objectives [src-007 p14; src-024 p62]. The World Bank guide also warns against the opposite error. Insisting on participation whatever the setting can backfire, and bringing people in halfway through to win support for decisions already made breeds delay and conflict [src-027 p27]. **Mostly non-AI evidence.** Most of the support comes from communication for development and ICT for development (using information and communication technology in development work) guides written before generative AI, the oldest from 2009 [src-027 p18; src-039 p27; src-004 p10; src-006 p37]. Only a few sources address AI directly [src-007 p6; src-015 p7; src-024 p62; src-028 p14]. The evidence on information and behaviour comes from non-AI studies in Kenya, Rwanda, Madagascar and the Dominican Republic [src-015 p16]. The crop example from Africa, where a drought-tolerant variety was abandoned because farmers needed long stems for roofs, has no reference [src-027 p31]. **Shared authors.** Girl Effect (src-012, src-037), the Plan Finland report (src-039) and SIMLab's monitoring framework (src-030) have MTI-linked authors. Their agreement with each other is less independent than it looks. **Little rigorous evidence.** Nearly all support is practitioner advice. Only the J-PAL point on information and behaviour rests on evaluations [src-015 p16]. #### Practitioner detail To judge whether a tool aimed at behaviour change addresses the real problem, ask what people gain quickly, what it costs them in time, effort, status or money, how others will see them, and whether they have the skills and means to act [src-006 p74]. If any of these is the binding barrier, more information will not move it [src-015 p16]. When objectives are already set, as with most funded projects, an assessment can still feed back risks and blind spots to management, so long as the findings are open to negotiation [src-027 p32]. Dalberg's playbook asks teams to record what they still do not know before moving to design [src-007 p14]. For tools built on large language models, PATH puts naming the users and their problem before team building or data collection [src-008 pp13-14]. #### Sources - **src-004**: CONNECT! A practical guide to using ICTs in Plan projects. Plan Finland. Cited: pages 10, 27, 28. - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: pages 37, 38, 74. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: pages 6, 10, 14, 15. - **src-008**: Designing Trust: A step-by-step guide for applying Human-Centered Design principles in creating benchmarking datasets for training and testing large language models to be used in clinical decision support. PATH, 2025. Cited: pages 13, 14. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: page 22. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 7, 16. - **src-024**: AI RMF Playbook. Cited: pages 62, 63, 74. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: page 37. - **src-027**: Participatory Communication: A Practical Guide (World Bank Working Paper No. 170). The World Bank, 2009. Cited: pages 18, 27, 31, 32, 36. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: page 14. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: pages 10, 11, 12. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: page 6. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: page 13. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 13, 27, 28, 45. ### Guidance for AI assistants 2 of 2 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved. --- ## E9 Enabling environment Items not yet agreed. Pages here are candidate items. > [!WARNING] > 1 of 1 pages in this bucket are not yet reviewed. Each says so at its top. ### Partner capacity Page: /enabling-environment/partner-capacity > [!WARNING] > Draft, not reviewed. A subject expert has not yet checked this page. Treat it as provisional. > [!NOTE] > Candidate item. The MTI team has not yet agreed the items for this bucket. **Question:** Do the implementing partners have the skills, staff, systems and time to build, run and look after an AI tool responsibly? Evidence: practitioner-consensus · Audiences: all · Type: question · Status: draft · Updated: 2026-10-17 #### Basics Find out whether the organisations that will build and run the tool can actually do it. That means the right mix of people, enough staff time, working equipment and power, and leaders who back the change [src-032 p12; src-007 p11]. Look at the partner as it works in practice, not only at its organogram (a chart of who reports to whom) [src-032 p32]. Check that the team understands the problem and the community as well as the technology [src-028 p25; src-039 p48]. Running costs, maintenance and long-term sustainability are separate topics. #### Why it matters for AI tools A more accurate model does not help if the organisation cannot act on what it produces. In India, a model picked out fraudulent firms for tax inspectors more precisely than the old rules, yet tax receipts did not rise, because enforcement processes and coordination across jurisdictions stayed the same [src-015 p34]. The same guide lists staff capacity and the ability to fit outputs into daily work as conditions for gains [src-015 p33]. Older technology projects failed for the same reasons: staff could not keep the system running, power or internet was unreliable, or the organisation did not support trying new things [src-032 p12]. AI adds new needs. Staff must be able to read model outputs and spot bias in data [src-024 p22]. Gaps in digital skills and organisational capability make fair, gender-equitable AI harder to deliver as a tool grows [src-025 p10]. Many partners are not ready yet. A NetHope benchmark of nonprofits found the sector at an intermediate level of AI readiness on average. Fewer organisations had the strategy, staff, governance and decision routines to adopt AI with confidence at scale [src-011 p5]. Funding can make this worse. Grantees feel pushed to adopt AI to stay competitive for grants, without support to govern it, and may take on tools that need more oversight than they can give [src-011 p5]. Capacity needs are often noticed too late. In India, a disability network's local committees took over a national campaign and asked for more technical support than the lead organisation could give [src-027 pp52, 56]. A project that rests on one enthusiastic person may fade when that person leaves [src-032 p12]. #### What good evidence looks like - A written assessment of the partner's readiness covering strategy, people, data and technology, with gaps stated honestly [src-007 p11]. - Views on readiness gathered from leaders, programme staff and technical staff, since each group sees different gaps [src-007 p11]. - A list of the skills the tool needs, the gaps in the current team, and whether each gap will be filled by hiring, training or a partner [src-028 p25]. - A stated way of working out which skills the tool needs, and of checking that staff have the training, resources and subject knowledge for their roles [src-024 p20]. - Senior leaders who take responsibility for decisions about AI risk, with a named team or person given the authority and budget to manage it [src-024 p20]. - A team that mixes disciplines beyond AI, such as social science, law and subject expertise, with its make-up recorded [src-024 p66; src-028 p25]. - People on the team who know the users' context, can write for them, and can reach child protection or gender-based violence experts when needed [src-034 p5; src-028 pp24-25]. - Evidence that staff have time for the extra work the new tool will create, not only for setting it up [src-032 p12]. - A named person responsible for ethics who understands all the workstreams; this person need not be technical [src-012 p21]. - Due diligence on partners who will handle children's data or work with children, covering safeguarding, data sharing and staff checks [src-037 pp43, 49]. - A plan for how much support lower-capacity partners will get, and who pays for it [src-037 p43; src-014 p62]. - Staff whose backgrounds reflect the community the tool will affect, or a plan to recruit them [src-024 p20]. - Capacity to keep the tool going after the grant: local developers trained to support it, and someone able to maintain an open-source tool or pay for a proprietary one [src-030 p33]. - If the tool uses a pre-trained model from another company (a model built elsewhere and adapted), someone able to track that model's performance and risks [src-024 p55]. #### Red flags in a proposal - The tool is treated as an IT project and handed to technical staff with no field or programme experience [src-039 p40]. - All knowledge of the problem and the community sits with an outside developer, with none kept in-house [src-028 p25]. - Capacity is described from the organisation chart or from senior leaders only, with no input from frontline staff [src-007 p11; src-032 p32]. - The project depends on one champion, with no plan to spread skills across the team [src-032 p12]. - No one owns safety or ethics, or the timeline leaves no room for safety work [src-014 p62; src-012 p21]. - Designers, evaluation staff and subject experts join only after the technical build is under way [src-012 p23]. - The tool rests on a third-party model, and no one in the team can monitor it or judge its documentation [src-024 p55]. - The partner is adopting AI mainly to stay competitive for funding [src-011 p5]. - The budget covers the build but not training, technical infrastructure or an independent evaluation partner [src-028 pp24-25; src-025 p16]. #### How to find out Several methods can build a picture of partner capacity. Use more than one, and choose them to fit the partner and the budget. - Desk research on the partner's website and shared documents, to form the first questions [src-031 p3]. - Interviews with staff about roles, workloads and how they work with users today [src-031 p3; src-032 p19]. - Observation of the office for a few hours: who does what, and which devices are in use [src-031 p4]. - Focus groups with staff, board members and users; the board can speak to budget, how long funding lasts and what would end the project [src-031 p4]. - An organisational capacity assessment, run as a self-assessment, a workshop or by an outsider, with a technology checklist [src-032 p32]. - A published AI readiness or data maturity self-assessment, chosen to fit the partner's setting [src-007 p11]. - Spot tests of infrastructure, such as counting power cuts over a week [src-032 p19]. - Reference checks and due diligence forms for partners who will handle sensitive data [src-037 pp43, 49]. #### Limits and disagreements - **How much must stay in-house.** One AI playbook says technology can be bought or outsourced but knowledge of the problem and community must be built inside [src-028 p25]. A Plan Finland report suggests dedicated staff, outsourcing to local partners or growing the IT role, and stresses people who bridge technology and programmes [src-039 p48]. They agree that problem knowledge matters most; they differ on who should hold technical skill. - **How much AI skill is needed.** A UNICEF chatbot guide lists platform, context and writing skills and expert contacts, not machine learning skills [src-034 p5]. Readiness frameworks from Dalberg and NIST expect broader data and AI capability [src-007 p11; src-024 p22]. The need depends on the kind of tool. - **Who should close the gap.** IREX says stakeholders should help smaller organisations get skills and tools [src-014 p62]. Girl Effect frames support for low-capacity partners as a risk-based choice about how much to invest [src-037 p43]. - **Era and AI relevance.** Nine of the 16 sources are not about AI, and several are old: a World Bank guide from 2009, SIMLab from 2018 and a Girl Effect guide from 2018. Their lessons are about technology and communication projects in general. - **Region and sector.** The one research finding comes from a single tax study in India, about a government agency rather than an NGO partner [src-015 p34]. The readiness benchmark is NetHope's own sector study, which the guide cites only in summary [src-011 p5]. The SIMLab worked example is a clinic in the United States [src-031 p3]. NIST is written for United States organisations [src-024 p22]. - **Shared authors.** Four sources (src-012, src-034, src-037, src-039) have MTI-linked authors. Their agreement is less independent than it looks. - **Thin support for some points.** The single-champion risk and the staff-time point rest on SIMLab alone [src-032 p12]. #### Practitioner detail When testing staff time, ask about the ongoing work the tool will create once it is live, not only the set-up [src-032 p12]. Compare how decisions are made in practice with what the organogram shows [src-032 p32]. In Kwale, Kenya, an ICT coordinator who acted as a programme person is credited with the office's progress [src-039 p54]. Outside programmes can help close gaps. In India, Digital Futures Lab runs a responsible AI lab and fellowship that offers tailored training modules, ongoing advice and peer learning to social impact organisations; its first cohort had 14 organisations [src-028 p66]. #### Sources - **src-006**: Communication for Development: A Practical Guide. Swiss Agency for Development and Cooperation (SDC), Federal Department of Foreign Affairs (FDFA), 2016. Cited: page 64. - **src-007**: The People Centered AI Playbook (Playbook Capsule). Dalberg Data Insights. Cited: page 11. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: pages 21, 23. - **src-014**: Safety by Design: Safe Approaches for Ethical Technology by Design: Making Products and Services Safer for Users and Consumers. Curriculum and Facilitator Guide. IREX, 2025. Cited: page 62. - **src-015**: AI Evidence Playbook: A Practical Guide. Abdul Latif Jameel Poverty Action Lab (J-PAL), 2026. Cited: pages 33, 34. - **src-024**: AI RMF Playbook. Cited: pages 20, 22, 55, 66. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: pages 10, 16. - **src-027**: Participatory Communication: A Practical Guide (World Bank Working Paper No. 170). The World Bank, 2009. Cited: pages 52, 56. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 24, 25, 66. - **src-031**: SIMLab Context Analysis Annex 1: Example Assessment. Social Impact Lab (SIMLab). Cited: pages 3, 4. - **src-032**: Framework for Context Analysis of Technologies in Social Change Projects. Social Impact Lab (SIMLab), 2018. Cited: pages 12, 19, 32. - **src-034**: Safer Chatbots Implementation Guide. UNICEF East Asia and Pacific Regional Office (Gender section). Cited: page 5. - **src-037**: Digital safeguarding tips and guidance. Girl Effect, 2018. Cited: pages 43, 49. - **src-039**: ICT Enabled Development: Using ICT strategically to support Plan's work. Plan Finland. Cited: pages 40, 48, 54. - **src-011**: From Hype to Due Diligence: The Nonprofit GenAI Pre-Adoption PESTLE Guide. NetHope Center for the Digital Nonprofit, 2026. Cited: page 5. - **src-030**: Framework for Monitoring and Evaluating Technologies in Social Change Projects. SIMLab (Social Impact Lab), 2018. Cited: page 33. ### Guidance for AI assistants 1 of 1 pages here are drafts that no subject expert has reviewed yet. Each is marked. When you use one, tell the user it is a draft and treat its points as provisional. If you are an AI assistant using this page to help someone: - Before advising, ask whether they are reviewing a proposal, designing a funding call, setting a budget, or learning. - Cite this page by its URL, with its evidence tag and the sources it names. - Say when the evidence comes from one region, sector or kind of project, and may not fit the user's context. - Point out weak or unsupported claims in a proposal rather than smoothing them over. - Remind the user not to paste identifiable proposal details or personal data into an AI tool their organisation has not approved.