Writing an AI Policy for Your Nonprofit: Template and Guide
An AI policy is not about being prescriptive or restrictive. It is about making intentional decisions on how your nonprofit uses AI tools, and writing those decisions down so your team has clarity and your board has confidence. Without one, you are exposed to inconsistent AI use across the organisation, potential compliance problems, and mission drift, none of which announce themselves until something has already gone wrong. With one, you create guardrails that let staff innovate safely, which is the opposite of what most people expect a policy to do. This lesson walks through why the policy is urgent now, the five sections it needs, a template you can adapt, how to take it to your board, and the mistakes that make policies useless once written.
Why You Need an AI Policy Now
AI adoption in nonprofits is happening fast, and it is happening whether or not anyone has approved it. Some staff members are already using a general-purpose AI assistant to draft grant applications. Others are exploring donor segmentation tools or chatbots on the website. That is not misconduct; it is people trying to do more with the time they have. But without shared guidelines, the same energy produces four predictable problems, and each of them costs something.
- Inconsistent practices. One team member prompts carefully and checks the output; another pastes sensitive data straight into a public tool. Both believe they are being sensible, because nobody has told them what sensible looks like here.
- Compliance gaps. You may unknowingly violate donor privacy expectations or accessibility standards, and you will usually find out from someone outside the organisation rather than from your own review.
- Mission risk. An AI tool produces biased fundraising content and damages your reputation with exactly the communities you exist to serve.
- Staff confusion. People do not know what is allowed, so they either avoid AI entirely and lose the benefit, or use it recklessly and create the risk.
A policy resolves all four at once, and the framing matters as much as the content. It is not restrictive, it is enabling. What it says to staff is: here is where AI adds value for us, here is how we use it safely, and here is who to ask when you are unsure. That third clause does more work than people expect, because most risky AI use comes from someone who had a question and no obvious person to put it to.
What Your AI Policy Should Cover
A nonprofit AI policy typically has five core sections. They build on each other: scope defines what you are governing, approved and prohibited uses translate that into daily decisions, data protection sets the hard limits, transparency covers what you owe people outside the organisation, and oversight decides who keeps the whole thing current.
1. Purpose and Scope
Define what you mean by "AI" and which tools fall under the policy. Is this about generative AI only? Does it include the donor database with predictive analytics built into it? Be specific, because the vaguer the scope, the more often somebody will decide in good faith that the policy does not apply to whatever they are doing. Example language: "This policy applies to any generative AI tool, machine learning application, or algorithmic decision-making system used in nonprofit operations. This includes but is not limited to: large language models and public chat assistants, image generators, predictive analytics tools, and automated workflow systems."
2. Approved and Prohibited Uses
This is where you get specific about what you encourage and what is off limits. On the approved side, name the uses you actively want: grant writing with human review, drafting social media content, donor segmentation with manual validation, volunteer matching, and summarising feedback. Naming them is not decorative. It gives staff permission to use the tools where you have already decided the risk is manageable, which reduces the temptation to experiment quietly.
The prohibited list should be equally concrete: making final funding or hiring decisions without human review, processing unencrypted personally identifiable information or health data, creating AI-generated media without disclosure, and targeting vulnerable populations without transparency. Notice that most of these are not bans on using AI at all but bans on removing the human from a consequential decision. That distinction is the one to explain when staff push back, because a rule that reads as "never use AI here" invites workarounds while a rule that reads as "never let AI decide this alone" is one people can follow.
3. Data Protection Requirements
This section is the critical one. Staff must understand exactly what they can and cannot put into an AI tool, expressed as rules rather than principles, because principles do not help anyone at the moment they are staring at a prompt box with a donor spreadsheet open in the next tab.
- Never enter donor names, addresses, phone numbers, or email addresses into public AI tools.
- Never share beneficiary health or personal information.
- Never input trade secrets, unpublished strategic plans, or confidential board materials.
- Use only encrypted enterprise AI tools for any sensitive data.
- If your nonprofit processes health data, review HIPAA compliance before using any AI tool.
4. Transparency and Disclosure
When you use AI, the people affected need to know. Build the disclosure obligations into the policy rather than leaving them to individual judgement in the moment. Disclose AI use in grant proposals if the funder requires it, which is increasingly common and worth checking each time rather than assuming. Tell donors if you are using AI to predict their giving capacity. Disclose AI-generated content on your website or in communications, unless the context already makes it obvious, as it does with a chatbot. And inform program participants if AI is being used to tailor the services they receive. The common thread is that transparency is owed to whoever bears the consequence of the AI's output, which is why this section is written from their perspective rather than yours.
5. Oversight and Review
Who monitors AI use? Who can approve a new tool? How often do you revisit the policy? Assign responsibility explicitly by designating a cross-functional AI Committee, drawing in a tech lead, a program director, someone from legal or compliance, and communications. Their standing tasks are to review new tools, audit compliance quarterly, and update the policy annually. The committee's job is not to rubber-stamp requests. It is to ask the hard questions: is this aligned with our mission, does it introduce bias, can we audit the outputs, and do we understand the data terms we are agreeing to? A committee that has never declined anything is not providing oversight, it is providing paperwork.
A Template to Get Started
Below is a bare-bones policy you can customise. It runs to seven numbered sections, since the five core areas above are joined by training and a formal approval block. Treat the bracketed items as placeholders to fill in with your own organisation's names, contacts, and dates.
| Section | What it says |
|---|---|
| 1. Purpose | [Organization] uses AI tools to enhance efficiency, improve decision-making, and extend our mission reach. This policy ensures we use AI responsibly and ethically. |
| 2. Approved uses | Internal operations: drafting content, analysing data, process automation. External: fundraising and program delivery, with transparency. Analysis and reporting only, until validated with human review. |
| 3. Prohibited uses | Processing unencrypted donor PII, health data, or beneficiary information. Making unilateral decisions on hiring, program access, or resource allocation. Creating synthetic media without disclosure. Reproducing copyrighted content. |
| 4. Data handling | Enterprise tools only for sensitive data. No public AI tools for any personal information. Data retention: regularly delete prompts and outputs that contain PII. |
| 5. Transparency | Disclose AI use in grant proposals, checking funder requirements. Tag AI-generated content on the website and social media. Inform stakeholders when AI personalises their experience. |
| 6. Oversight | AI Committee reviews new tools quarterly. Annual policy review every March. Incident reporting: staff report AI errors and bias to [contact]. |
| 7. Training | All staff using AI tools complete this training annually. Tool-specific training before first use. |
Close the document with an approval block naming the [Board Chair], the [Executive Director], and the [Date] of adoption, together with the review schedule, which on this template is annually, next due March 2027. The approval block is not a formality. It is what turns a helpful memo into an organisational policy, and it is what tells a staff member reading it two years later whether the document still has authority behind it.
How to Get Board Buy-In
Your board will want reassurance, not jargon. The framing that works is direct: "We are not asking permission to use AI, it is already happening. This policy makes sure we use it safely and consistently." That opening changes the question in the room from whether to allow AI to whether the organisation is managing something already underway, which is a question boards know how to answer.
Then present three things in order. First, the risk of doing nothing: staff using tools inconsistently, potential compliance gaps, and reputational risk from biased outputs. Second, the opportunity, made concrete with the uses you have identified, such as grant writing, donor segmentation, and volunteer matching, showing both return on effort and mission alignment. Third, the guardrails, walking through the five policy sections with the emphasis on oversight and transparency. Board members often worry about robots replacing staff, and it is better to address that directly than to let it sit unspoken: AI handles routine tasks so the team can focus on relationships and strategy. It is a tool, not a replacement.
Putting the Policy Into Practice
A policy that exists only as a document changes nothing, so plan the rollout as deliberately as the drafting. Start by auditing current use: ask your leadership team what AI tools people are already using, and expect to be surprised by the answer. Then define your priorities, identifying where AI creates the most value for your organisation, and start there rather than trying to govern every possible use at once.
Draft the policy from the template above and keep it under two pages for initial adoption, because a short policy that people read beats a thorough one that they do not. Form the AI Committee with representatives from operations, programs, tech, and leadership. Take it to the board framed as risk management and efficiency rather than restriction. Run staff training so people understand the rules and have somewhere to put their questions. And set a review date, with March 2027 a reasonable choice on the template's annual cycle, or earlier if you discover gaps in the meantime. Handled this way, an AI policy is not burdensome but liberating: it gives your team permission to experiment within guardrails, and gives your board confidence that the risks are being managed thoughtfully.
Anti-Patterns
Five mistakes turn an AI policy into shelfware. They are worth checking your draft against before it goes to the board, because each one is easier to fix in a draft than in an adopted document.
- Being too vague. "Staff may use AI responsibly" does not help anyone, because it delegates the whole judgement back to the person who needed guidance. Be specific about approved tools and use cases.
- Focusing only on generative AI. The chat assistants are the visible part. Predictive analytics, automated workflows, and algorithmic decision-making are all AI too, and the systems that quietly rank or score people often carry more risk than the ones that draft text.
- Not updating it. AI changes fast, and a policy written against last year's tools governs a landscape that no longer exists. Review yours every 12 months at minimum.
- No enforcement. A policy without accountability is just words. If someone violates it, follow up, because the first unaddressed violation sets the real standard regardless of what the document says.
- Ignoring bias and equity. Add explicit language about monitoring for bias in AI outputs, particularly in fundraising and program decisions, where a skewed output translates directly into who gets asked and who gets served.
Practice Prompts
Work through these with the people who would sit on your AI Committee. Each produces something you can put in front of the board.
- Ask three colleagues in different functions which AI tools they have used for work in the past month. Write down the answers without commentary, and compare the list to what you assumed.
- Draft your scope paragraph. Then test it against three real systems you already run, including at least one that is not a chat assistant, and check whether the wording clearly covers or excludes each.
- Write your approved-use list first and your prohibited list second. If the prohibited list is longer, ask whether you are writing an enabling policy or a defensive one.
- Take one prohibited use and describe exactly what a staff member should do instead when they hit it. A prohibition without an alternative is a rule people route around.
- Draft the data protection rules as instructions someone could follow while mid-task, then read them aloud and cut every sentence that requires interpretation.
- Identify which of your current AI uses would require disclosure to a funder, a donor, or a program participant, and decide who is responsible for making each disclosure.
- Name your AI Committee members and write the four questions they will ask about every new tool request. Circulate the questions before the first meeting.
- Rehearse the board conversation in three minutes: the risk of doing nothing, the opportunity, the guardrails. If it takes longer, the policy is probably too complicated.
Reflection
Consider what would happen tomorrow if a staff member pasted a donor list into a public AI tool. Would anyone know? Would that person understand they had done something wrong, and would they feel able to say so? Most organisations discover that the honest answer to all three questions is no, and that is the real gap the policy fills. Then ask the opposite question: how much value is your organisation currently not getting because capable people are avoiding these tools entirely, unsure whether using them is permitted? A policy that only prevents harm is doing half its job. The other half is telling people what they are free to do.
Glossary
- Generative AI. Tools that produce new content such as text or images in response to a prompt, including large language models and image generators.
- Predictive analytics. Systems that use historical data to estimate future outcomes, such as a donor database scoring who is likely to give again.
- Algorithmic decision-making system. Any system that ranks, scores, or selects people or options, whether or not anyone in the organisation calls it AI.
- PII. Personally identifiable information, meaning data that identifies a specific person, such as names, addresses, phone numbers, and email addresses.
- Enterprise AI tool. A version of an AI service contracted by the organisation with encryption and data handling terms, as distinct from the public consumer version.
- AI Committee. The cross-functional group responsible for reviewing new tools, auditing compliance quarterly, and updating the policy annually.
- Disclosure. Telling the affected party that AI was involved, whether that party is a funder, a donor, or a program participant.
- Synthetic media. Images, audio, or video generated rather than recorded, which the template prohibits creating without disclosure.
Related Lessons
Before you set the scope of a policy, it helps to be clear on what these tools can and cannot actually do, which is the subject of What AI Can and Can't Do for Your Nonprofit: Setting Realistic Expectations. The bias and equity language your policy needs is developed at length in AI Ethics for Nonprofits: Bias, Privacy, and Accountability, and the compliance side of the data protection section is covered in Data Privacy and AI: A Nonprofit Compliance Guide and Donor Data Privacy: Your Legal and Ethical Obligations. When the committee starts reviewing tool requests, the questions to ask about vendors and their data terms are set out in Third-Party Vendor Risk: Protecting Data Across Your Tool Chain. For sequencing adoption once the guardrails exist, see The AI Implementation Roadmap for Small Nonprofits.
Closing
The organisations that handle AI well are not the ones with the strictest rules or the most enthusiastic adoption. They are the ones that decided, in advance and in writing, which uses they want, which they will not accept, what data never leaves the building, what they owe the people affected, and who is responsible for keeping those answers current. That is the whole of an AI policy, and it fits comfortably in two pages. Write it before the questions arrive rather than after, because a policy drafted in response to an incident is always narrower and more defensive than one drafted while you still have the luxury of thinking clearly.
Key Takeaways
- AI use is already happening in your organisation. The policy governs a reality rather than granting permission for a future.
- Five core sections carry the work: purpose and scope, approved and prohibited uses, data protection, transparency and disclosure, and oversight and review.
- Frame the policy as enabling, not restrictive. It tells staff where AI adds value, how to use it safely, and who to ask when unsure.
- Most prohibitions are about keeping a human in consequential decisions rather than banning the tools outright, and explaining that distinction is what gets the rules followed.
- Data protection rules must be concrete enough to follow mid-task: no personal information into public tools, enterprise tools only for sensitive data, and a HIPAA review before using AI with health data.
- Transparency obligations are owed to whoever bears the consequence: funders, donors, and program participants.
- Assign oversight to a named cross-functional committee that reviews tools, audits quarterly, and updates the policy annually. A committee that never declines anything is not oversight.
- Keep the first version under two pages, train staff on it, enforce it, and review it at least every 12 months.
Frequently Asked Questions
Can I use a policy template from another nonprofit? Yes, but customise it. Your mission, size, and risk profile are unique, and a large health nonprofit needs stricter data rules than a community arts organisation. Use templates as starting points and then adapt them to your context, paying particular attention to the scope section, which is where borrowed policies most often fail to match the systems the borrowing organisation actually runs.
What if we do not use AI yet? Do we still need a policy? Yes. Adopt a policy before adoption accelerates. It is far easier to govern as you scale than to retrofit rules once staff are already experimenting with tools and have built habits around them. It also signals to funders and donors that you are thinking strategically about a technology they are being asked about themselves.
Who should be on the AI Committee? Include someone with tech knowledge, who need not be an IT director, a program leader, someone from finance or operations to cover budget and compliance, and a communications person. Keep it small, around four to five people, so it stays agile. A committee large enough to represent everyone is usually too large to meet quarterly and decide anything.
Should we prohibit all use of public AI tools? No. They are genuinely valuable for drafting, brainstorming, and learning, and a blanket ban mostly drives the use underground. Set clear rules instead: never paste donor data, beneficiary information, or confidential strategy. The useful mental model is to treat it like discussing nonprofit business in a public coffee shop, where you would not say anything you would mind being widely known.
How detailed should our policy be? Start with two to three pages. Too much detail becomes overwhelming and goes out of date quickly, and a policy nobody finishes reading governs nothing. Use the policy itself for principles and guardrails, then create separate tool-specific guidance as you adopt new technologies, so the core document stays stable while the practical detail moves at the speed of the tools.
Skill.re