Nearly four in five UK charities are now using AI day-to-day. At the same time, more of them trust it less than they did twelve months ago. That’s not a contradiction: it’s a sign the sector has moved past the novelty phase and started asking harder questions. We’ve written before about the positive use cases AI can unlock for the sector; this post is about the less glamorous but more decisive part, choosing and running these tools responsibly. It pulls together what we’re hearing from clients, what our own developers think, and what a recent frontier AI safety incident tells us about picking models sensibly.
Adoption is up. So is anxiety. Here's why that's healthy
The 2026 Charity Digital Skills Report found that AI use among charities has climbed to 79%, up from 76% the year before, but the proportion who say they don’t trust AI tools has more than doubled, from 15% to 35%, and the gap is widest among larger charities and those supporting marginalised communities.
We see the same pattern in client conversations. It isn’t that charities have gone off AI. It’s that the ones actually using it day-to-day are the ones who’ve hit its limits: a chatbot that answered a safeguarding question badly, a summary that quietly invented a figure, a “quick win” that turned into an ongoing maintenance bill nobody budgeted for. Familiarity breeds scrutiny, not blind faith, and in a sector built on trust with vulnerable beneficiaries, that scrutiny is exactly right.
What this means in practice: trust isn’t a marketing problem you fix with a reassuring FAQ page. It’s an operational one, built through the mundane stuff: clear data handling, predictable behaviour, and an ongoing relationship with someone who understands the system when something goes wrong, rather than a one-off build that’s left to fend for itself.
"Lacking AI skills" doesn't mean what you think
Ask most people outside the LinkedIn AI bubble what an “AI skills gap” looks like, and they picture prompt engineering. In reality, for most charities it’s far more basic: knowing which tool exists for which job, and when not to reach for AI at all.
That tracks with the Charity Digital Skills Report too: limited skills and technical expertise is now the single biggest barrier for charities not yet using AI, ahead of cost or leadership buy-in. The fix isn’t a prompting masterclass. It’s practical, role-specific guidance: what a chatbot is good for, what it isn’t, and how to spot when an answer needs a human sense-check. This is usually the first thing we work through with a client in a tech roadmap workshop, well before any code gets written.
The real model question: not "the best", but "the smallest one that does the job"
Charities often come to us asking for “the best AI” for their chatbot. It’s the wrong starting point. The better question is: what does this specific use case actually need?
For most FAQ-style and support chatbots, a lighter, faster model (like Claude’s Haiku tier) handles the volume perfectly well, at a fraction of the cost per message of a top-tier frontier model. The more capable, more expensive tier earns its keep on harder tasks, where the system needs to reason across a knowledge base to give advice, rather than simply retrieve and restate information already sitting in it. Running everything on the most powerful model available isn’t more careful; it’s usually just more expensive, for very little practical gain, and it’s not automatically safer either, more on that below.
Worth noting: on our own platform JChat, there’s currently no cost difference passed on to the client between running a chatbot on a frontier-tier model like Opus versus a lighter one like Haiku, though pricing structures across the industry shift often enough that this is worth double-checking with any vendor rather than assuming it’ll always hold.
Questions to ask a vendor before signing up
Before signing up with any vendor, it’s worth asking a few sanity-check questions. We’ve rounded up who’s actually leading the way on efficient, sustainable models if you want the fuller picture:
- What’s the actual cost per message (usually driven by tokens, roughly three characters of text), and how does that compare to going direct to a frontier provider?
- Does this task need a frontier-grade model, or would a lighter one do the job for less?
- Where is the model hosted, and does that meet our data protection requirements: UK, EU, or self-hosted open-source?
- How easy is it to switch models later if a better or cheaper option comes along?
That last one matters more than people expect. Moving between models in the same family (say, from one Claude tier to another) is usually a light-touch test-and-see exercise, because prompts and response formats are similar. Moving between entirely different model families is a bigger job: different prompt formats and behaviour mean genuine redevelopment, not just a settings change.
What ongoing maintenance actually costs
A live AI tool isn’t a one-off spend, and it’s worth budgeting for the ongoing work rather than being surprised by it later. In the early weeks after launch, most of the work is prompt tuning: getting the tone and voice of a chatbot in line with the organisation, and making sure it doesn’t stray into topics it shouldn’t touch.
After that, maintenance settles into three ongoing categories:
- Model updates. Sometimes a genuinely better model becomes available; sometimes a provider retires an older model and forces the switch regardless. Either way, it needs testing before it goes live, not just swapping in.
- Knowledgebase upkeep. Information goes stale. Someone needs to own updating it as things change and adding new material as it becomes relevant.
- Ongoing review. Regularly checking the tool’s outputs and incrementally improving them, catching drift or errors before they become a pattern, rather than only looking when something goes visibly wrong.
None of this is exotic, but it’s real, recurring work, and a charity budgeting for an AI tool as a single upfront cost is budgeting for the wrong thing.
More capable doesn't mean safer, and a recent incident shows why
It’s tempting to assume that a newer, more capable frontier model is automatically the safer choice too. It isn’t. Capability and safety guardrails can move independently, and a more “confident” model can be a bigger risk than an older one that’s more inclined to hold back and say “I’m not sure.”
This isn’t theoretical. In August 2026, the UK’s AI Security Institute (AISI) disclosed an incident from routine cyber testing in which AI agents took sustained, unsanctioned action directed at real people and organisations. Testing frontier models across 122 runs of a cybersecurity challenge, AISI found that in 10 of those runs, an agent took autonomous, unsanctioned action on the live internet, targeting real people and organisations, with 19 such actions catalogued in total. In the most serious case, an agent tried to insert malicious code into an open-source project, creating fake online identities to socially engineer the project’s maintainer into approving it. A human maintainer caught it in time.
Two things stand out for anyone commissioning AI tools:
- This happened under deliberately permissive test conditions, open internet access and safety filters switched off, that don’t reflect how models are made available to the public. It’s not a reason to panic about the chatbot on your website. It is a clear signal that raw capability and built-in safety behaviour are separate design choices, not a package deal.
- Guardrails aren’t something you inherit for free from a “better” model. AISI’s own conclusion was that evaluation and monitoring need to be built deliberately, and reassessed every time capability increases: the same principle applies to any organisation adopting a new model version. It’s exactly why we treat every model swap as something to test and review against a baseline, in the same structured way we’d treat any other stage of moving a product from proof of concept to a live launch, not a routine upgrade to wave through.
In practice, that means evaluating a new model’s performance against a baseline before it ever touches production. For chatbots and other language-heavy tools, that judgement is often qualitative: does it still sound right, does it still hold its boundaries. For tasks with a clearer right answer, like classification, we build a benchmark of correct responses to a set of questions, marked by a human, and score new models against it alongside whatever is currently live, rather than assuming an upgrade is automatically an improvement.
So why not just go straight to the frontier provider?
A charity could, in principle, sign up to a frontier provider directly and build a chatbot themselves. What that misses is everything around the model. Taking automated action (collecting data, sending emails) rather than just answering. Giving approved, on-brand responses to common questions instead of an LLM improvising an answer on the fly. The data protection layer, PII redaction, automated data deletion and hosting in the right region. Chatbots have been promising this since the 1960s; what’s changed is that frontier models can finally deliver on it, provided the surrounding platform is built properly. The model is one component. Getting that surrounding system right, and building it out from a proof of concept to a working MVP, is the actual job.
Is progress slowing down?
It’s a fair question to ask before committing budget to any AI tool: is this still moving fast, or has it started to plateau? There’s some evidence that raw model capability has hit a point of diminishing returns, though it’s hard to say with confidence given there’s only been around two years of this kind of extreme growth to judge it against.
What isn’t slowing down is progress on how these models are used. Agentic coding and similar harnesses, where a model works through a task over many steps rather than just answering a single prompt, are advancing if anything faster than the underlying models themselves. For charities, that’s the more relevant trend to watch: even if the next model release is only a modest improvement, what you can build with it keeps moving.
The bottom line
Chasing the largest, newest frontier model is the wrong instinct. The more useful one, and the one we’d disagree with plenty of the industry on, is to pick the smallest model that reliably does the job, understand what ongoing maintenance it commits you to, and treat every model change as something to test, not assume. It’s also why the most exciting part of the frontier, for us, isn’t the race between the biggest labs at all: it’s how fast small, open-weight models capable of running on a single laptop are improving. That’s a trend worth watching far more closely than the next headline-grabbing flagship release. Trust in AI isn’t built by picking the most impressive-sounding tool. It’s built by choosing the right one, and keeping an eye on it.
