# Stage 0 research for AI funders: all content > Curated good practice on Stage 0 (formative) research, for funders who review proposals for AI tools. Built by The MERL Tech Initiative. Source: https://mti-gedc.baobabtech.app. Every page is also at its own URL, listed in https://mti-gedc.baobabtech.app/llms.txt. Pages marked draft or in review have not been checked by a subject expert. --- ## 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] > 1 of 1 pages in this bucket are not yet reviewed. Each says so at its top. ### 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-17 #### 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 Stage 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]. 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]. #### 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 [src-032 p11; src-011 p7]. - 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 covers sector and channel rules, such as licences for bulk SMS, ID rules for SIM registration, or limits on automated calls [src-032 p10; src-018 p22]. - 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 explains how consent will be obtained and how the law's consent rules will be met [src-028 pp28-29]. #### 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]. - 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]. 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]. #### 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 pp45-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]. 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]. Several points rest on older or non-AI sources. SIMLab dates from 2018 and covers SMS and mobile projects [src-032 pp10-11]. 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]. #### 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]. 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 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. - **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, 35, 36. ### 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. --- ## 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] > 1 of 1 pages in this bucket are not yet reviewed. Each says so at its top. ### 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-17 #### 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]. 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]. 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]. #### 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]. #### 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]. - **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.** Only three of the fourteen extracts behind this file concern AI tools: AI farm advice [src-003 p8], AI flood alerts [src-015 p15] and responsible AI practice [src-028 p54]. 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), and Senegal (Plan staff) [src-022 p1; src-015 p39; src-026 p4; src-026 p18; src-039 p85]. Some extracts give no country. None of it comes from Latin America. - **Age of evidence.** The ODI field guide dates from 2015 and the UNICEF review from 2013. 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]. 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. - **src-003**: AI-Enabled Farmer Advisory: Risk & Failure Taxonomy. Cited: pages 8, 10. - **src-016**: Gender Formative BIG Research questions. Cited: page 2. - **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, 39. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: page 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. ### 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. --- ## 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]. 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]. 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]. - 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]. #### 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]. 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]. #### 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: - Six of the ten 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]. None gives a worked example of a landscape review for an AI tool. - 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]. #### 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. - **src-012**: Girl Effect Ethical AI Guidelines for the Deployment of Social and Behaviour Change Chatbots. Girl Effect, 2025. Cited: page 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: page 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. ### 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]. Stage 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]. - 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]. #### 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]. #### 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]. - **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, 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. - **src-025**: Gender Equitable AI Toolkit. NetHope's Center for the Digital Nonprofit. Cited: pages 7, 9. - **src-028**: The Practice Playbook on Responsible AI. Digital Futures Lab. Cited: pages 8, 26. - **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: page 13. - **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]. 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]. 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]. - 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]. - 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]. #### How to find out Several methods can surface harms, and each misses some things. 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]. #### 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]. - 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. #### 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]. #### 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 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: page 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 35, 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 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, 46, 47. - **src-024**: AI RMF Playbook. Cited: pages 1, 9, 62, 71, 83, 85, 93. - **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. - **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, 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 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-17 #### 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]. #### 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 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]. #### 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. 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]. 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, 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, 43, 44. - **src-016**: Gender Formative BIG Research questions. Cited: page 3. - **src-024**: AI RMF Playbook. Cited: pages 38, 43, 62, 63. - **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-17 #### 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]. - 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]. - 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]. **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. - **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, 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]. 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 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]. #### 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 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.** Eight of the 14 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 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]. #### 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 22, 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. - **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. ### 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.