What AI can actually do for a four-person team

Most guidance on AI for nonprofits is written by people who have never filled in a donor report. It talks about transformation. What a four-person team needs is a short list of things that must never happen, and a shorter list of things worth starting on Monday.

Here is the version I would hand a new colleague.

Think of it as a layer, not a colleague

The most common failure is expecting a tool to understand your organisation on its own. It does not know your mission, your donor’s reporting template, the local context, the terminology your sector uses, or how sensitive the work with your beneficiaries is.

Without that, it produces something generic. With it, it becomes genuinely useful.

The useful mental model is a layer sitting between information your team already has and the output it needs to produce. Meeting notes go in, an action plan comes out. A field report goes in, a newsletter draft comes out. A human controls what goes in and approves what comes out. The value is in the middle, never at either end.

Five things that should never be delegated

Decisions about beneficiaries. Who receives assistance, who meets eligibility criteria, whose case takes priority. A model can organise the information. Decisions affecting people’s rights stay with people.

Safeguarding and safety assessments. Risk of violence, child protection concerns, mental health, emergencies. These need a named, qualified person and a written procedure.

Legal and financial interpretation. Contracts, tax obligations, employment law, donor rules. A first-pass summary is fine. A final answer is not.

Publishing without review. A mistake in an internal draft costs a correction. A mistake in a public statement costs credibility, and in this sector credibility is most of what you have.

Personal data, without a clear rule. Names, addresses, identification documents, medical information, anything about children, anything about violence or vulnerability. Write “a minor beneficiary from a rural community reported a safety concern”, not the name and the village. And know that a combination of small details can identify somebody even after you have removed the name.

What a good instruction contains

A useful instruction is not long. It has five parts, and the fourth is the one people skip.

Role. Whose perspective. A project coordinator in a small international organisation.

Context. What it needs to know. Youth aged 15 to 24, employability programme, rural communities.

Task. Exactly what to do. Turn these meeting notes into an action plan.

Constraints. What not to do. Do not invent deadlines, responsible people or results. Where information is missing, write “to be defined”.

Format. What the output looks like. A table with task, owner, deadline, status, open questions.

That constraint line is what separates a usable draft from a confident fabrication. Models produce plausible statistics, plausible legal references and plausible quotations, and a report containing an invented figure is worse than no report at all.

How to pick your first process

A process is a good candidate when it happens often, eats real time, works on text, has a clear beginning and end, follows stable rules, and produces something a human can check quickly enough to catch an error before it does damage.

Good first choices: summarising a call for proposals, turning meeting notes into tasks, adapting one project update into four channels, grouping open-ended survey answers into themes.

Bad first choices: anything on the never-delegate list above.

Four weeks, one process

Week one, ask everyone which task they repeat most and which one eats the most time. Week two, pick one that is frequent, simple and low risk. Week three, write one standard instruction and test it on five real examples, recording what it gets wrong and where it invents things. Week four, write down what goes in, which instruction to use, what to check, who approves, and where the result is stored.

Only once that manual workflow is boring should you consider connecting it to anything else.

How you know it is working

Track four numbers and be honest about them. How long the task took before and after. Whether the output needs more corrections or fewer. Whether everyone on the team now produces work of a similar standard. And whether you have increased the chance of an inaccuracy, a leak, or a decision you would struggle to defend.

Time saved is not a benefit if the risk went up. That trade is easy to make by accident and hard to explain to a donor afterwards.

The exercise

List five tasks your team does regularly. For each: how often, how long, could a model help, and what is the risk if it gets it wrong.

Then pick exactly one that takes at least thirty minutes, happens at least monthly, contains no personal data, and produces something a person can check in two minutes.

That one is your first workflow. Not five. One.