Writing your nonprofit's first AI policy

A good nonprofit AI policy is shorter than you think and easier to write than you fear. It is not a thick legal document that anticipates every scenario. It is one page that names a few clear principles and tells your team how to make good calls when you are not in the room. Your first AI policy should fit on a single page, lead with principles instead of prohibitions, and be something your staff will actually read and use.

The orgs that get stuck are the ones waiting for the perfect, exhaustive rulebook. You do not need that. You need a living document, grounded in how your org actually works, that you can approve this quarter and refine as you learn. Start with principles, write plainly, and ship it.

Why principles beat prohibitions

The instinct with a new technology is to write a long list of what staff cannot do. That approach fails for a simple reason. AI changes faster than any list of rules can keep up, and a wall of prohibitions tells your team what to fear without teaching them how to think.

A principle is portable. "Protect donor data" guides a decision your policy never anticipated. "Do not paste names into tool number seven" expires the moment a new tool appears. Principles also signal trust, and trusted teams make better calls than policed ones.

This does not mean no rules. A few hard lines matter, and we will get to them. The frame is principles first, with specific rules where the stakes are high enough to require them. You are writing a compass, not a fence.

What should a nonprofit AI policy include

A useful AI policy answers five plain-English questions. Get these right and you have covered what matters without drowning anyone in detail.

• How do we handle data? The single most important section for a nonprofit. Sort your data into tiers: what can never go into any AI tool, what is fine only in enterprise tools with real data protection, and what is low-risk and free to use. Donor names, giving histories, and any client or beneficiary details belong in the protected tiers.
• When do we disclose AI use? Decide where you stand on transparency. Many orgs disclose on public-facing content and keep internal drafting unflagged. Pick a position and give staff a standard line to use so they are not guessing case by case.
• What requires human review? Name what cannot go out without a person approving it: donor communications, grant submissions, press releases, board materials. AI drafts. A human decides. That signoff is what keeps your quality and your reputation yours.
• Which tools are approved? Keep a short, current list of the tools your org sanctions, with a preference for enterprise versions that meet a real data protection bar. When staff know the approved set, shadow tools stop creeping in.
• Who is accountable? Name one person or role that owns the policy. Not "everyone," which means no one. The owner keeps the tool list current, answers questions, and runs the review.

A policy your team will actually read beats a comprehensive one that lives in a drawer. One page, five clear answers, and a named owner does more than thirty pages nobody opens.

A one-page AI policy outline you can use

Here is the skeleton. Each line is a section heading. Fill it with your org's real decisions, keep the whole thing to a page, and write it in plain language. This mirrors the structure we use in the AI policy starter inside our toolkit.

• Purpose. One or two sentences on why this policy exists and what it is meant to protect.
• Scope. Who it covers: staff, volunteers, contractors, board, and whether it applies to personal AI use on work accounts.
• Approved uses. The work AI is cleared for, like drafting appeals, summarizing notes, or researching prospects.
• Prohibited uses. Your hard lines, such as pasting donor data into free tools or letting AI make funding or eligibility decisions.
• Data handling. Your data tiers and the rule for each: never, enterprise-only, or free to use.
• Disclosure. When and how your org discloses that AI was involved, with a standard line for staff.
• Human review. What requires signoff before it ships, and who is authorized to give it.
• Accountability and training. Who owns the policy, how staff are trained, and what happens if someone breaks it.
• Review cycle. How often you revisit the policy and what would trigger an off-cycle review, like a new tool or a funder requirement.

Two notes before you publish. Flag anything that touches legal or compliance obligations for review by qualified counsel, especially if you work with minors, health data, or funders with strict data requirements. And add a one-paragraph staff quick reference at the end, the plain-language version your team can scan in thirty seconds.

How do you keep your AI policy from going stale

A policy is not a monument. It is a document that has to keep pace with how your org actually uses AI, which means it needs an owner and a rhythm.

Three habits keep it alive:

• Review it on a schedule. Once or twice a year, the owner walks through the policy with leadership and updates what has drifted.
• Trigger off-cycle updates when reality changes. A new tool, a new funder requirement, or a near-miss with data should prompt a fresh look before the next scheduled review.
• Train to it. A policy nobody was taught is a policy nobody follows. A short walk-through when it launches, and again when it changes, does more than any amount of fine print.

Your first AI policy does not have to be perfect. It has to exist, fit on a page, and reflect real decisions your team can act on. Once it does, you have given your staff something better than a list of fears. You have given them the confidence to use AI well.

What does a good AI policy actually sound like

Plain language is the whole game. A policy written in legalese gets filed and forgotten. A policy written like a colleague explaining the rules gets followed. Aim for sentences your newest staff member could read once and act on.

Compare the two registers. "Personnel shall not transmit personally identifiable donor information to non-enterprise generative AI platforms" says less, and lands worse, than "Never paste donor names or giving amounts into free AI tools." Same rule. One of them your team will remember.

A few habits keep the writing usable:

• Lead each section with the decision, not the rationale. Say what to do first. If the why matters, add one short sentence after.
• Prefer "do this" over "do not do that" where you can. Tell staff which tools are approved rather than listing every tool that is banned.
• Name the person, not the department. "Ask the development director" beats "consult the appropriate authority."
• Keep examples concrete. A single real example of a safe use and an unsafe one teaches more than a paragraph of principle.

One question comes up often: should the policy disclose that AI helped write your content? That is your call to make, and the honest answer is that most orgs land on transparency for public-facing work and quiet drafting for internal documents. What matters is that you decide on purpose and write the position down, so staff are not making it up donor by donor.

Remember that the policy is a tool for your people, not a shield for your org. Its job is to help a real person make a good decision at 4 p.m. on a deadline, when you are not there to ask. Write it for that moment and it will earn its place.

If you want help making those decisions, the policy is part of the broader work we do. Our Mission Ready path includes the toolkit and templates to build one yourself, and when your board is ready to engage on governance, here is how to have the board conversation about AI that turns policy into momentum.