Community-Centered AI: Involving the People Nonprofits Serve
Most AI projects in the nonprofit world are designed in offices, by staff, consultants and vendors. The people whose lives the tools will affect, such as tenants seeking housing support, families using a food pantry or students applying for scholarships, usually appear only as data points. They are counted, scored and sorted, but rarely asked.
That gap matters. A tool built without the people it serves can be technically sound and still miss the point: it may rely on information people are reluctant to share, use language that feels cold or confusing, or optimize for outcomes the community does not value. Community-centered AI starts from a different premise. The people affected by a system should help shape it, test it and judge whether it is working.
This article sets out what community-centered AI means in practice, why it leads to better tools, and how nonprofits with limited time and budgets can involve the people they serve at each stage.
Why the People Served Belong in the Process
Nonprofits often say they are accountable to their communities, but technology decisions tend to follow a different path: a problem is defined internally, a vendor is chosen and the community meets the result at launch.
Better Problem Definitions
Staff may assume the main obstacle to a service is paperwork, while the people using it point to opening hours, transport or fear of how their information will be used. Asking first can change which problem a tool is meant to solve, or show that AI is not the right answer at all.
Fewer Blind Spots
People with lived experience notice things that designers miss: a question on an intake form that feels intrusive, a chatbot reply that sounds dismissive, a category that does not fit their situation. Catching these early is far cheaper than fixing them after trust has been damaged.
Legitimacy and Uptake
Tools people helped shape are tools they are more likely to use and trust. Involvement does not guarantee acceptance, but exclusion makes resistance much more likely.
Levels of Participation
Involvement can mean very different things, from a single survey to shared decision-making. Being honest about which level an organization is offering avoids raising expectations it cannot meet.
| Level | What It Looks Like | Community Influence |
|---|---|---|
| Inform | Explaining how a tool works and how data is used | Low: people know, but cannot change it |
| Consult | Surveys, interviews, feedback on prototypes | Moderate: input is gathered, staff decide |
| Co-design | Community members join design and testing sessions | High: shapes features and wording |
| Shared governance | Community seats on the group that approves and reviews the tool | Highest: can pause or change the system |
Not every project needs the top level. A tool that schedules volunteer shifts may only need clear information. A system that helps decide who receives emergency grants deserves co-design and ongoing community oversight.
Involving Communities at Each Stage
Participation works best when it is built into the project timeline rather than added at the end.
Before Choosing a Tool
Hold listening sessions on the problem itself, not on a solution already picked. Ask what gets in the way, what has worked before and what worries people about automation. Bring the findings into vendor conversations.
During Design and Testing
Invite a small group of service users to try prototypes on realistic tasks. Watch where they hesitate, ask what they expected to happen and adjust. Wording, tone and language options often change more than the underlying model.
After Launch
Create simple ways to report problems and ask for a human, and review that feedback regularly with community members, not only with staff. The risks described in AI bias in philanthropy often show up first in the experiences of people the system treats differently.
A practical option is a small standing panel of service users who meet a few times a year to review complaints, sample outputs and any changes the vendor proposes. Rotating membership keeps the panel from becoming a closed circle, and sharing a short summary of each meeting with the wider community shows that the feedback is taken seriously rather than filed away.
If the people a tool affects cannot question it, correct it or opt out of it, the tool is being done to them, not built with them.
Doing It Fairly and Respectfully
Participation has costs for participants. Asking people with limited time and resources to contribute expertise for free repeats the imbalance community-centered work is meant to correct.
- Pay participants for their time, and offer childcare, transport or meals where relevant.
- Hold sessions at times and places that suit participants, not staff schedules.
- Offer materials in the languages people actually use, with plain explanations of technical terms.
- Explain how input will be used, and report back on what changed as a result.
- Protect participants’ privacy, especially when they share sensitive experiences.
Avoiding Token Involvement
A common pattern is to hold one consultation, collect feedback and proceed exactly as planned. People notice. If input cannot change a decision, say so upfront. If it did change something, show them what.
Making It Part of How Decisions Are Made
Community involvement lasts when it is written into policy rather than left to the enthusiasm of one project lead. The framework in building an AI policy for your nonprofit can include a simple rule: any tool that affects eligibility, access to services or how people are contacted requires community input before approval.
Questions to Ask Vendors
Ask whether the vendor has tested its product with people similar to those the organization serves, whether wording and workflows can be changed based on community feedback, and whether the tool supports a clear route to a human. A vendor that cannot accommodate these requests may not be the right partner for sensitive work.
A Hypothetical Example
Imagine a tenant-support nonprofit planning a chatbot to answer questions about rent assistance. In early sessions, residents explain they are wary of typing personal details into a website and often help neighbors who do not read English well. The team narrows the chatbot to general information, adds two more languages and keeps a phone line staffed for anything involving personal circumstances. The final tool is smaller than first planned, and far more likely to be used.
Building Tools People Recognize as Their Own
Community-centered AI is slower at the start. It takes more conversations, more revisions and more humility about what staff and vendors do not know. In return, it produces tools that fit real lives, earn trust and are less likely to cause quiet harm.
For organizations committed to strengthening relationships rather than replacing them, this is not an optional extra. The people a nonprofit serves are the reason it exists. Giving them a real voice in the systems that affect them is simply what good service looks like when the service includes software.
