AI Research Methods for Nonprofits

Nonprofits are being sold AI faster than almost any other sector, and with less capacity to check what they are buying. Vendors arrive with discounted nonprofit pricing, a compelling demo, and a claim about hours saved. The staff evaluating that claim are usually programme people with no budget for a technical consultant and no time to run a proper trial.

This curriculum is the response to that gap. It is not a course on building AI, and it is not a tools tour. It teaches a nonprofit team to do research — to ask what evidence would make a claim true, to generate that evidence cheaply from their own data, and to reach a decision they can defend to a funder.

Why this curriculum exists

Sector surveys have consistently found that a large minority of nonprofits are already experimenting with AI, concentrated in fundraising and communications, and that adoption is growing considerably faster than evaluation capacity. That mismatch is the actual risk. An organisation that adopts a tool which quietly performs badly on its specific caseload does not usually find out from a benchmark — it finds out from a mis-triaged case or an embarrassing donor communication, months later.

The core argument of this curriculum is that evaluation is cheaper than most nonprofits assume, and much cheaper than a failed rollout. A useful evaluation set is fifty examples, not fifty thousand. A useful pilot is one programme area for six weeks, not an organisation-wide transformation. The skills required are closer to monitoring and evaluation practice — which most nonprofits already have — than to machine learning.

Who this is for

This works best for a mixed group of six to twenty people spanning programme delivery, monitoring and evaluation, fundraising, and operations. Mixing functions matters: the fundraising team's enthusiasm for a donor-scoring tool and the safeguarding lead's concerns about case data need to meet in the same room, working from the same evidence, rather than negotiating by email after a purchase decision.

It is a poor fit for organisations looking for a hands-on prompt-writing workshop, or for teams that have already committed to a specific vendor and want validation rather than evaluation.

What the two days actually look like

Day one — reading claims

The morning establishes what can and cannot be known about an AI system from the outside. Participants learn the difference between a benchmark score, a demo, a case study, and a controlled comparison, and why the first three are frequently compatible with a tool that will not work for them.

The afternoon is adversarial and hands-on. Groups take three real vendor pitches — anonymised, drawn from actual nonprofit-sector sales material — and for each one write down the single piece of evidence that would most change their confidence. This is usually the moment the framing clicks: the question stops being "is this tool good" and becomes "good at what, measured how, on whose data."

Day two — generating your own evidence

The morning builds an evaluation set. Participants bring anonymised historical examples from their own work — past grant applications, case summaries, donor queries, whatever the candidate tool claims to help with — and assemble roughly fifty examples with known correct answers. This artefact is the durable output of the whole programme. It outlives any particular tool, and it can be reused every time a new vendor appears.

The afternoon turns that into a pilot protocol: a baseline measurement of current performance, an explicit success threshold agreed before the tool is run, a stop rule, a duration, and a named owner. Teams leave with this written down and signed off in the room, which is the single highest-value artefact of the two days.

What we deliberately do not cover

• Model building or fine-tuning. Almost no nonprofit should be training models, and a curriculum that implies otherwise is selling the wrong ambition.
• Tool-specific instruction. Tools change faster than a curriculum can track; evaluation methods do not.
• Procurement and contract law. Important, but a different specialism — we cover the technical evidence that should inform procurement, not the contracting itself.

Governance and data constraints

Data classification is treated as a gate, not an afterthought. Before any evaluation runs, teams work through which categories of their data can leave the organisation at all: donor personal data, beneficiary case notes, safeguarding records, and financial information each carry different constraints, and in some jurisdictions and some programme areas the honest answer is that a cloud-hosted model is not an appropriate destination regardless of how well it performs.

Teams that reach that conclusion have not wasted the exercise. Establishing clearly that a category of work is off-limits, and documenting why, is a legitimate and valuable outcome — and considerably cheaper to reach in a workshop than after a data incident.

Related curricula

AI safety and guardrails for healthcare teams covers a similar evaluation discipline in a higher-stakes setting, and ChatGPT for work is the better starting point for teams who need day-to-day usage skills first.

Related programmes and reading

This curriculum pairs naturally with broader evaluation and governance work. For background reading before a session, participants often find these useful:

• How to read AI benchmarks — the single most relevant prerequisite article for day one
• What is an AI benchmark, and what does it actually measure?
• Responsible AI and governance for teams
• AI interpretability and monitoring for teams

Sessions are delivered by explainx.ai and can be scoped to a single programme area or run across an entire organisation. Curricula are adapted to the sector, data constraints, and jurisdiction of the specific organisation rather than delivered from a fixed deck.