AI in Non-Profits and Research Organisations

Two constraints define this sector and neither is a smaller version of a corporate one. The budget is low enough to change which model you pick, and the people in your records are frequently people for whom a data breach has consequences no insurer covers.

A budget that changes the engineering

When the ceiling is a few tens of pounds a month rather than a few thousand, choices that are rounding errors elsewhere become the design. Three of them do most of the work.

• Size to the task, not to the demo. Classification, tagging, extraction into a fixed schema and translation of routine material are handled by small models at a fraction of the price, and the quality difference on a constrained task is often not visible. The decision procedure is in is a small model enough.
• Batch anything nobody is waiting for. Archive tagging, transcription backlogs, translating a report — none of it is interactive. Where a provider offers a discounted asynchronous tier in exchange for latency tolerance, that is free money for this sector specifically, because almost nothing here is urgent. Batch inference and the batch discount cover the shape.
• Cache the fixed part. A long system prompt describing the organisation, its programmes and its style is re-sent on every call. Where prompt caching is available, that prefix is the thing it is for — when caching pays back gives the break-even.

Then put a hard ceiling on the account with an alert well below it. The failure that hurts a small organisation is not a slightly high bill; it is a loop left running over a weekend by a volunteer with an API key. Budget controls and denial of wallet are worth an hour before anything else is built.

The most sensitive data in this cluster

A charity’s case records can contain immigration status, asylum claims, health conditions, safeguarding concerns, addresses that are confidential because someone is fleeing, and details about children. This is more sensitive than most of what appears in the corporate verticals on this site, and the asymmetry that matters is in consequence: a company harmed by a leak has lawyers and insurance, and the person in a case record has neither.

The default should therefore be that identifiable beneficiary data does not go to a general-purpose external service at all. That is a stronger default than “check the terms”, and it is affordable because the useful tasks mostly do not need it:

• Summarising a policy or a funder’s guidance — no personal data involved.
• Drafting communications, appeals and reports — aggregate figures only.
• Aggregate analysis of case themes — run over de-identified extracts, and note that free-text case notes resist de-identification, because a combination of town, condition and circumstance can identify one person even with names removed.
• Anything genuinely requiring the record — either not automated, or done on infrastructure the organisation controls. See redaction, self-hosting and retention terms.

Research organisations have a parallel version of this. Data collected under an ethics approval and a participant consent form was collected for a stated purpose, and sending transcripts to a third-party service may be a processing activity that consent did not cover. That is a question for the ethics committee before the analysis, not a technical one, and the answer is sometimes no.

Assembling evidence is not inventing it

Grant writing is the application every non-profit asks about, and it divides cleanly into a task that is a genuine win and one that is fraud.

The win is assembly. A funder asks eleven specific questions; the organisation has answered versions of them in eight previous applications, three annual reports and a monitoring return, and the evidence exists in its own monitoring data. Retrieval over the organisation’s own material, followed by drafting that reuses its own previously-approved language and its own figures, turns a fortnight into an afternoon and produces something more accurate than a rushed rewrite, because it is anchored to what was actually reported.

The other thing is a model producing an outcome figure, a beneficiary count or an impact statement that the organisation cannot evidence. That is a false statement in an application for funds, and dressing it up as a first draft does not change what it is. The engineering control is the same one used everywhere else in this cluster: numbers come from the monitoring system by lookup, never from the model, and any figure in a draft carries a citation to where it came from. A draft containing an uncited number does not go out.

The same rule protects a research organisation writing up findings. Language models are useful for structure, for a literature summary whose citations are then verified one by one, for translating a methods section into plain language and for tidying prose. A citation that has not been checked against the actual paper is not a citation — fabricated references is the specific failure and it is well documented.

Building something nobody has to maintain

The hidden constraint is staffing. There is often no one whose job it is to keep a system running, and the volunteer who built it will move on. That argues for a particular kind of choice, and it is worth being explicit about because it is the opposite of what a technically strong volunteer will propose:

• Prefer a feature inside a tool the organisation already pays for and already knows how to administer over a bespoke integration, even when the bespoke one is better.
• Where something is built, keep the entire configuration — prompts, model choice, thresholds — in one documented place a non-specialist can read and change.
• Write down what happens when it stops working: who to tell, and how the work gets done without it. If the answer is that the work stops, the dependency is too deep.
• Give every automated output a named human owner. A tagging pass that nobody reviews degrades silently as models and data change, and quiet degradation is much harder to notice without monitoring nobody here is going to build.