Should your charity build its own AI? Almost certainly not — here's what to do instead

A question we keep hearing from boards and management committees across the social service sector — charities, social service agencies (SSAs), NGOs, nonprofits of every size — in one form or another: "Everyone says we need AI. Should we build our own, so our data stays private? Or is it safe to use ChatGPT?"

It's a good question, and the honest answer is short. But the reasoning behind it is where the confidence comes from — so let's walk through it in plain English, for the people who run programmes, not the people who run servers.

The simple version of how AI models get made

Every general-purpose AI model you've heard of — Claude, ChatGPT, Gemini — is built roughly the same way: a very large neural network, fed enormous amounts of text across thousands of specialised computers for months, then refined by specialist teams to be helpful and safe. Publicly reported estimates put the cost of training a single frontier model in the hundreds of millions of dollars.¹ Only a handful of companies in the world do this.

So when a job advertisement or a consultant says "AI/ML expertise," it almost never means building models. It means using them well — connecting AI to your organisation's data and workflows, choosing the right tier of service, and putting sensible guardrails around it. That reframing matters, because it turns an impossible question ("can we afford to build AI?") into a manageable one ("which way of using it fits our data and our budget?").

The privacy worry is real — but it's about the wrong version

Here's the thing most people get wrong, and it changes the whole conversation:

The privacy concern that makes headlines comes from consumer AI tools. Enterprise tiers are governed by different, contractual terms.

• Free and personal accounts (the ChatGPT or Claude app someone downloads themselves): depending on the plan and settings, conversations may be used to help train future models. Anthropic, for example, updated its consumer terms in 2025 so that chats on Free, Pro and Max plans may be used for model training unless the user opts out, with retention of up to five years for those who allow it.² OpenAI's own help pages say it directly: ChatGPT "improves by further training on the conversations people have with it, unless you opt out."³ This is the version people are rightly worried about when staff paste client information into it.
• Business and enterprise tiers (Claude for Work, ChatGPT Enterprise/Business, and the APIs developers build on): the published terms say the opposite. Anthropic's commercial terms state plainly that "Anthropic may not train models on Customer Content from Services."⁴ OpenAI states that data from ChatGPT Enterprise, ChatGPT Business and its API platform is not used for training by default.³ These tiers also come with admin controls, audit logs, and independently audited security certifications (SOC 2 Type II, ISO 27001 and similar).⁵ That's a contractual commitment you can show your board and your auditor — a different thing entirely from a marketing promise.
• Stricter still: the same commercial models are available through the major cloud platforms — for example, Anthropic's Claude models through Amazon Bedrock, including in AWS's Singapore region⁶ — so processing can run inside your organisation's own cloud environment. For Singapore organisations, note the nuance: the PDPA does not require data to stay in Singapore — its transfer limitation obligation requires comparable protection wherever data goes — but a Singapore-region deployment can make that conversation much simpler. (More on the PDPA in our plain-English PDPA & AI guide.)

One practical habit follows from all of this: whatever vendor you use, get the commitments in writing — is our data used for training, where is it processed, how long is it retained, is there a data processing agreement? A vendor who can't answer crisply hasn't thought about it. And check the terms yourself before relying on them; they do change, which is why every claim in this article carries a "checked" date at the bottom.

Why "build your own" rarely makes sense

There are really two versions of "build your own", and they fail for different reasons:

Training a model from scratch is simply not an option for anyone outside a handful of frontier labs. The cost is measured in hundreds of millions of dollars and specialist teams that don't exist on the open market at charity salaries. Nobody advising a social service agency to "build its own AI" means this — and if they do, walk away.

Running an open-source model on your own servers (a model like Meta's Llama, downloaded and self-hosted) is genuinely possible, and it's the maximum-control option: data never leaves your building. But three things are true at once. You now need engineers to secure, patch and maintain it. The open models you can realistically run tend to lag the leading commercial models in capability. And — the part people find counterintuitive — your security posture is often weaker in practice than a major cloud provider's, because Amazon, Microsoft and Google employ thousands of security engineers and your organisation doesn't. In our view, self-hosting only earns its keep for organisations with extreme confidentiality requirements and a real engineering team to match.

The practical ladder, in order of effort

For a social services context with sensitive client data, our honest read is that step i (the enterprise subscription) or step ii (the API-built internal tool) — plus a clear staff policy — gets you roughly 95% of the value with the privacy handled. Climb higher on the ladder only when a specific requirement pulls you there, not because it feels safer in the abstract.

The risk nobody budgets for: shadow AI

Here is the observation that changed how we advise on this, and it comes from sitting in social sector organisations, not from vendor brochures: the biggest real-world AI risk isn't the vendor. It's staff quietly using free consumer AI tools on their phones because the organisation gave them nothing official.

Freeze the decision for a year while a committee deliberates, and the AI use doesn't stop — it just goes underground, onto personal accounts, on exactly the tier of tool where conversations may feed future training runs. The caseworker pasting a client email into free ChatGPT at 9pm isn't malicious; she's drowning, and it helps. A sanctioned, safe option plus a short, clear policy — "never client data in consumer AI tools; use the org account; a human checks every output" — is itself the safety measure.

To make that easy, we've written a free one-page staff AI-use policy template for Singapore charities — printable, adaptable, written to sit alongside the PDPA obligations you already have. Take it, adapt it with your DPO, and you've closed the gap that actually causes incidents.

Frequently asked questions

Where we fit — and our interest, disclosed

Full transparency: we have a commercial interest in this topic. GoodTechHoldings builds software for the social sector — Socianote for case management and donor work, and custom AI-assisted workflows of exactly the kind on step ii of the ladder above ("API + your own app"). So weigh our advice with that in mind.

That said, notice what this article actually recommends for most organisations: step i of the ladder — an enterprise subscription you buy directly from the AI vendors, which involves us not at all. If that's all you need, that's what we'll tell you. Where we earn our keep is when a chat window isn't enough — when the job needs your data, your access controls, and workflows designed so the AI sees the minimum. And if we think a workflow is too sensitive for AI entirely, we'll say so; that stance is in writing in our PDPA guide. Worth reading next if funding is the blocker: the grants that co-fund digitalisation for Singapore charities.