Relief Applications

AI policy for NGOs: what to include and how to write it

Your staff are probably already using AI tools, with or without a rule. An AI policy turns that into a decision: which tools, for which work, with what data, and who answers for the result. This guide sets out what the policy should say, how to write it in a few weeks, and which public frameworks to borrow from.

The short answer

An AI policy for an NGO is a short document that says which AI tools staff may use, for which tasks, with which data, who is accountable for the results, and how new uses are approved and reviewed. It does not need to be long. Two to four pages that people can follow beat a forty-page document nobody reads. Start with the data rules, because most of the real risk for NGOs is what gets typed into a tool, then add roles, approval and a review date.

Why does an NGO need an AI policy?

Three things push NGOs to write one. Staff already use general-purpose AI tools, often on personal accounts, to draft, translate and summarise. Funders and partners increasingly ask how you manage AI. And the people NGOs serve are often in situations where a wrong or careless output does real harm.

The first one is the easiest to picture. A team uses a public chatbot to summarise interview notes or to draft a proposal that contains confidential details, and nobody has decided whether that is acceptable. The policy does not have to forbid it. It has to make the decision visible, so that the team knows where the line is.

This is the situation behind one of our projects for the Centre for Disaster Protection, where the staff were using AI tools on an ad hoc basis. In six weeks we wrote an AI readiness report, a governance strategy and a phased roadmap. The case study says more.

What should an AI policy cover?

The headings below fit most organisations. Keep each to a few sentences, and add a worked example where a rule is easy to misread.

Purpose and scope
What it says: Who the policy applies to (staff, consultants, volunteers, partners) and what counts as AI: chatbots, writing and translation tools, image tools, tools built into software you already use. The question it answers: Does this apply to me and to this tool?
Principles
What it says: A few commitments that guide the rest, such as humans stay accountable, we do not harm the people we serve, we are open about where we use AI. The question it answers: What do we stand for?
Approved and prohibited uses
What it says: Tasks where AI is allowed, allowed with conditions, or not allowed. The question it answers: Can I use it for this?
Data rules
What it says: What may never be entered into an external AI tool: personal data of the people you serve, staff records, security information, unpublished donor material. What may be entered, and into which tools. The question it answers: What can I paste in?
Accountability
What it says: A named owner for the policy, and the principle that the person who uses an output is responsible for checking it. The question it answers: Who answers for this?
Human oversight
What it says: Where a person must review before anything reaches a beneficiary, a donor or the public. No decision about a person is made by AI alone. The question it answers: When must a human check?
Transparency
What it says: When you tell people they are dealing with AI, and when you say AI helped produce a document. The question it answers: Do we disclose it?
New uses and tools
What it says: How a team proposes a new AI use or tool, who reviews it, and what the review looks at. The question it answers: How do we add something?
Suppliers and contracts
What it says: What you ask a vendor: where data is stored, whether your data trains their model, how you leave. The question it answers: Is this tool safe to buy?
Incidents and review
What it says: How to report a problem, and when the policy is reviewed. The question it answers: What if it goes wrong, and when do we update?

Why are the data rules the most important part?

Most of the real risk for an NGO is not the model. It is what the staff put into it. A data rule that people can apply in a second is worth more than any principle.

One simple approach, our own suggestion and not a standard, is a three-level scheme. Level one is information that is already public and can go into any approved tool. Level two is internal information, such as draft plans without names, which can go only into tools you have approved. Level three is personal data about the people you serve, staff or partners, security details and anything covered by a confidentiality duty. It does not go into an external AI tool unless a review, which may include a data protection impact assessment, has approved that exact use.

If your organisation is in scope of the GDPR, sending personal data to a vendor’s model is a processing activity with the usual duties: a lawful basis, a contract with the vendor, and a check on where the data goes. Ask your data protection officer, or read our guide on whether an NGO needs a DPO. Where AI tools are built into software you already use, read the supplier’s terms to see whether your content is used to train their models.

Which public frameworks can you borrow from?

You do not have to invent the structure. Three public sources are useful, each for a different purpose.

  • The NIST AI Risk Management Framework, version 1.0 (2023), describes four functions: Govern, Map, Measure and Manage. Govern covers culture, accountability and policy and runs through the others. Map sets the context and supports a first go or no-go decision. Measure tests and monitors, before deployment and during operation. Manage allocates resources to the risks you found and plans for incidents. The functions are not a rigid sequence, and they are useful as a checklist for your own approval process. NIST says a revised version is in progress, so check its site. See the NIST AI RMF.
  • The OECD AI Principles come from the Recommendation of the Council on Artificial Intelligence, adopted in 2019 and revised in 2024. They set out five values-based principles: inclusive growth, sustainable development and well-being; human rights and democratic values, including fairness and privacy; transparency and explainability; robustness, security and safety; and accountability. They are a good source for the principles section of your policy. See the OECD AI Principles.
  • The CDAC Network’s SAFE AI work is closest to the sector’s reality. Its framework treats the participation of affected communities as part of governance, and a separate briefing note sets out the main categories of risk when humanitarian organisations deploy AI. See CDAC Network SAFE AI and the briefing note Risks in humanitarian AI.

Laws also apply to some organisations, depending on where they operate and what they build or buy. The EU’s AI Act is one example. Ask legal advice about what applies to you, because this guide does not.

How do you write the policy in a few weeks?

  1. Find out what is already happening. A short, honest survey of staff on which tools they use and for what is worth more than a workshop. Promise that it is not a disciplinary exercise.
  2. List the use cases, not the tools. “Drafting donor reports”, “translating community feedback”, “summarising interviews”, “answering questions from beneficiaries”. Tools change. Use cases last.
  3. Sort the use cases by risk, using the data levels above and the effect on people. A summary of a public report is low risk. A chatbot that answers people in crisis is high risk.
  4. Write the rules. Start with the data rules and the list of approved uses. Draft in plain words and test each rule on a real example.
  5. Name the owner and the approval route. Small organisations can use a short review by the person responsible for data protection, someone from programmes and someone from IT.
  6. Train the staff and publish it where they will find it. A policy that lives in a shared folder is not a policy.
  7. Set a review date. AI tools change quickly. Review at least once a year, and sooner after an incident.

For a team that wants help, our AI and interactive tools service covers readiness reviews and governance, and the privacy and cybersecurity service covers the data protection checks that go with them.

How should a new AI use be approved?

The approval route is where a policy becomes real. Keep it light for low-risk uses and thorough for high-risk ones. A one-page form is enough to start. It asks five things.

  • What is the use case, and who benefits?
  • What data goes in, and where does it go? Which level is it?
  • Who checks the output, and before what happens next?
  • What could go wrong for a person, and how would we know?
  • Who owns it, and when is it reviewed?

Anything that talks to the people you serve deserves the most care. The use of a language model in a chatbot needs rules on what it may and may not say, a way for a person to take over, and a check on what is stored. Our guide to humanitarian chatbots goes into this.

What mistakes do NGOs make with AI policies?

Copying a corporate policy
Why it hurts: It talks about products, shareholders and risks you do not have, and misses the duty of care to the people you serve. What to do instead: Start from your own use cases and the sector’s guidance
Banning everything
Why it hurts: People carry on in private and you lose sight of what is used. What to do instead: Allow low-risk uses openly and give a route for the rest
Writing only principles
Why it hurts: Nobody knows what to do on Monday morning. What to do instead: Add data rules and examples people can apply
No owner
Why it hurts: Nobody updates it or answers questions. What to do instead: Name a person and a review date
Forgetting the vendors
Why it hurts: Your data may leave your control through a tool you did not look at. What to do instead: Ask where data is stored and whether it trains the vendor’s model
Leaving out the people you serve
Why it hurts: Tools can fail the people with the least power to complain. What to do instead: Involve communities in decisions about tools that affect them

Questions and answers

Does a small NGO need an AI policy?

If any staff use AI tools for work, yes. A small organisation can use a two-page policy with data rules, a list of approved uses, a named owner and a review date.

How long should an AI policy be?

Two to four pages is enough for most NGOs. Put the data rules and the approved uses on the first page so that people can use it without reading the rest.

Can staff paste beneficiary data into ChatGPT or similar tools?

Not without an approved review. Personal data about the people you serve should not go into an external AI tool unless you have assessed that exact use, the vendor’s terms and where the data goes. Many policies simply prohibit it.

Which framework should we follow?

You do not need to follow one strictly. The NIST AI Risk Management Framework is useful for structuring approval and review, the OECD AI Principles for the principles section, and CDAC Network guidance for humanitarian settings.

Do we have to tell people when we use AI?

Your policy should say when. A good rule is to tell anyone who is talking to an AI system that they are, and to say when AI helped write something that reaches the public. Check the law that applies to you.

How often should we review it?

At least once a year, and after any incident. AI tools and the rules around them change quickly.

Talk to us about AI at your organisation

We review your use cases, compare the options, and write the governance that goes with them. Tell us what your teams already use.

Keep reading

This guide is general information, not legal or technical advice. Reviewed on 11 November 2026 by the team at Relief Applications. The NIST, OECD and CDAC Network frameworks are described from their own public pages and may have changed.