AI for Nonprofits: a starter guide

Last month I asked AI to research a funder and it told me not to apply. The tool found a geography mismatch and a two-year lockout after a decline, both of them in documents I had not read closely. It was right. The reason I could act on what it told me is that I spent about four minutes verifying the two facts that actually drove the decision.

That verification step is the one I see skipped most often, and it is where this guide starts.

The trouble with fluent answers

AI writes well. That is the first thing most people notice, and it is also where the trouble starts, because we are trained to read fluency as a signal of competence. When a well-organized, confident, grammatically clean paragraph arrives on your screen, some part of your brain has already filed it as reliable before you have evaluated a single claim inside it.

In a lot of contexts that costs you very little. In our work it lands on grant narratives, donor communications, board reports, and program data, where being wrong is expensive and tends to stay invisible for months. A funder does not write back to tell you which sentence in your application was inaccurate. They just decline you.

What literacy actually means here

When people talk about building AI literacy, most of them mean understanding roughly how the technology works. I have read a fair number of those explanations. They are interesting, and they did very little for the quality of my decisions.

The literacy that changed my work is narrower. It is the ability to look at something AI just produced and know which parts you can act on and which parts you have to go check. That skill sits much closer to editing than to engineering, which is good news for nonprofit people, because most of us have spent years editing other people's work already.

You are mostly applying judgment you already have to a source you are not yet in the habit of doubting.

Four questions to ask of anything AI hands you

1. Can I name the source, and can I go look at it? Ask where a claim came from, and then actually open the page. If it cannot point you somewhere specific, treat the claim as a hypothesis rather than a fact. This one catches a lot, because the failure is rarely a wild invention. It is usually a plausible detail with no particular origin.
2. Would I have caught this if a person wrote it? You already have editorial standards, and you apply them to staff work and board drafts without thinking about it. The odd thing about AI output is how readily we suspend those standards for it. Read the page as though a colleague handed it to you and your name is going on it, because in every way that matters, that is the situation.
3. What would this look like if it were wrong? Ask directly for the counter-case. In funder research that means asking for the three reasons this foundation would decline you. In a program report it means asking which conclusion the data does not actually support. It takes one sentence to turn an agreeable assistant into one that will argue with you, and the argument is usually where the useful part is.
4. Is this a fact question or a judgment question? Facts need verification against a source. Judgment needs your context, and it is not something you can hand off. Whether a funder's deadline is October 1 is a fact, and you can check it in thirty seconds. Whether your program story is strong enough to spend your one annual application on is a judgment, and it belongs to the people who know the program.

Most bad outcomes I have seen come from treating the second kind of question as though it were the first.

The two-week exercise I would start with

This is what I would do first, and it takes two weeks.

Take a grant you already won and ask it to assess your fit against that funder. Take last year's year-end appeal and ask it to segment the donor list you already segmented by hand. Take a program report you wrote yourself and ask it to pull out the outcomes.

You are not trying to save any time with this. You are calibrating. You are watching where it is genuinely sharp, where it is confidently vague, and where it manufactures a detail because the shape of the answer seemed to call for one. Two weeks of that gives you a feel for it that is hard to get any other way.

The reason it works is that it drops your checking cost to zero. When you already know the answer, verification is instant, so you can afford to run twenty of them in an afternoon.

Most people go about this in the opposite order. They hand AI the hardest thing on their desk on day one, get back an answer they have no way to evaluate, and then either trust it more than they should or decide the whole category is overhyped. Both of those outcomes come from the same missing step.

Once you can judge the output yourself, the next question is what the organization allows. This is the same problem one level up.

A board member once told me that using AI to help write our donor letters felt like cheating. I think she was raising something worth taking seriously. That conversation was easier than the one I had in August, when I sat down with our technology lead and our leadership team and had to name exactly which documents a staff member may paste into an AI tool and exactly which ones would get them a phone call from me.

The values question, briefly

The worry usually arrives in one of three forms. There is a fear about authenticity, since donors gave to people rather than to a machine. There is a fear about integrity, since automating part of the work can feel like cutting a corner. And there is a fear about identity, since if a tool can do a piece of the work, you start to wonder what that says about the work.

My answer, worked out over about a year, is that staff time in a nonprofit is the scarcest resource on the balance sheet and the one most directly tied to the mission. A business that automates routine work turns the saved hours into profit. A nonprofit that automates routine work turns the saved hours into mission. Every evening a program manager loses to reformatting a report is attention the families never receive, and we have simply grown used to absorbing that cost without calling it what it is.

I am moving past it here because the values conversation has a comfortable property, which is that it never has to be specific. You can hold it for eighteen months. I have watched organizations do exactly that, and at the end of it their staff are still using AI, just without any rules, on personal accounts, with nobody able to say what went where.

Why our first draft failed

A written policy has to be specific in a way a conversation about values does not.

Our first draft said something close to "be careful with client data." I read it back and realized I had written a hope rather than a rule. Careful is not a decision procedure. A housing counselor with a case note she needs help structuring cannot act on careful. She needs to know whether this specific document, the one in front of her, is allowed, and she needs to know it quickly enough that checking is not its own task.

So the policy we ended up with does one job. It tells you which bucket a document falls into before you put it into the tool.

The three buckets

This was approved as written by our technology lead and leadership on August 8, 2026, and it is now the rule at Habitat for Humanity of Michigan. What follows is the core of it rather than the whole document. I am publishing it because it is more useful to you than a blank template would be. Take it, change the specifics to match your own funders and systems, and put your own name on it.

Three buckets is the design. A staff member can hold three categories in their head while looking at a document, and they cannot hold a two-page policy. That is why most AI policies get read once during onboarding and then stop affecting what anybody actually does.

The four decisions underneath it

Writing the buckets took a couple of hours. The decisions underneath them took considerably longer, and they are the ones I had not seen discussed anywhere when I went looking.

Where the connected folder lives

These tools work by being pointed at a folder on your computer, and the natural instinct is to point them at the folder where the files already are, which for most of us is a synced cloud drive. The consequence is that everything in that folder becomes reachable by default, including whatever syncs in next month that nobody consciously decided to expose. We chose a separate local working folder that staff copy files into deliberately. The extra copying step is the point of it, because copying a file forces you to look at it and decide, and that decision is exactly what the three buckets are asking for. The vendor's own safety guidance recommends the same thing, so the conservative option was also the recommended one.

Whether sessions run on your machine or the vendor's

On our plan there is an organization-wide setting controlling whether the work executes in the vendor's cloud or locally, and it ships turned on. This one went against my recommendation. I had a weak preference for turning it off on the grounds that a smaller surface is easier to explain, and leadership decided the convenience was worth it, which is a defensible call. The consequence landed on me rather than on them, because it means I can no longer tell staff their work stays on their laptop. The training module now says plainly that sessions run on the vendor's infrastructure. That is how it should work. I brought the tradeoff, they made the call.

The feedback buttons

On the plan we use, content submitted through the thumbs up and thumbs down control may be used for model training, and feedback submissions carry a five-year retention window rather than the ordinary deletion timeline. It is the only route by which our content could reach training. We disabled it organization-wide, which took about a minute and seemed more reliable than training people to avoid a button that appears beside every response.

System connections

Whether the tool may be connected to your database, your file storage, or your email. Our answer for this phase is no, written down plainly so it is a rule rather than a judgment call, and the training tells staff to assume the answer is no and not to attempt a connection. We will revisit it once the rollout has a track record.

The two decisions about people

I expected the technical decisions to be the hard ones. These two have mattered more in practice.

Who does someone ask when they cannot tell?

A three-bucket policy still produces edge cases, and an edge case with no owner becomes a guess. We named a person for judgment questions and a second person for technical ones, and we committed to answering within twenty-four hours. The response time is the part that does the work, because if asking takes three days then guessing is the rational choice and your policy has stopped applying.

What happens when somebody gets it wrong?

Somebody eventually will, given a new tool, real deadlines, and a document that looks green from one angle. We made the reporting procedure blameless and specific: delete the conversation, tell the named person, and it gets logged and reviewed.

That framing is self-interested rather than generous. A mistake nobody reports is one you cannot correct, and it is also the one that surfaces eighteen months later in a funder conversation with no warning. A policy that frightens people produces the same number of mistakes and costs you the ability to hear about them.

What the policy costs us

Earlier this year I ran an AI audit across five departments at Habitat Michigan and interviewed staff about their actual daily work. That audit is Part 3 of this guide. The two largest time savings it found are both in the red bucket. Case note drafting after counseling appointments currently runs thirty to forty-five minutes per appointment. Assembling a closure portfolio means manually converting Word files, photographs, and PDFs into a single submission document. Both involve client information that is not going anywhere near this tool under the policy I just wrote.

The reasoning is that the safe work is substantial on its own. Affiliate correspondence, process documentation, grant narrative drafting, class attendee reporting, and internal communications are all sitting in the green bucket and all of them consume real hours today. Starting there builds a track record. In a few months I can go back to our technology lead with evidence about how this has actually been used rather than with a proposal about how it might be. That is a considerably stronger conversation than the one I could have this month.

The organizations that get into trouble with this are usually the ones that started with the hardest and most sensitive use case because it had the biggest number attached to it.

If you are writing one of these

Take the buckets above, change the document types and funder names to match your work, and get it approved before you train anybody. The order matters more than the wording. A policy written after staff have already formed habits is a correction, and corrections are much harder to land than rules.

Our AI audit came back with 21 things we could build. Twelve of them were rated high impact. The work that actually got finished since then was all from the easy end.

Where the list came from

Last spring I sat down with people across five departments at Habitat Michigan and asked each of them to walk me through their real work. I wanted the honest version rather than the job-description version, including the parts everybody knows are wasteful and nobody has time to fix.

Twenty-one opportunities came out of those conversations. Each one got scored twice, once for how much it would help and once for how hard it would be to build.

The shape of the list

Twelve of the 21 are rated high impact. Only four of those twelve are also low difficulty.

The easy end

The four that are high impact and low difficulty are almost boring to read.

A searchable home for our written procedures, so people stop asking the same three colleagues the same questions about lien removal and HUD system steps. Meeting recordings turned into task lists and follow-up drafts. Reply drafts for the client emails we answer forty times a month, the ones asking about status, missing documents, and next steps. Triage on a shared inbox so the urgent items surface above the routine ones.

None of that will impress anyone at a conference. All of it can be running inside a week, set up by the person who actually has the problem, with no purchase order and no IT ticket.

The hard end

The four at the other end are the ones you actually want.

One client record that holds together across four systems that do not currently talk to each other. A documentation setup for our housing counselors, who spend thirty to forty-five minutes writing up every appointment and enter a good deal of it in two places. Automated compliance checking on the hardest ten percent of our closings, which is where nearly all of the pain in that program lives. Electronic intake forms, so nobody has to retype a PDF into a spreadsheet ever again.

Those four are bigger projects that will come once the basics are in place.

The reasons have nothing to do with the quality of AI. Every one needs systems connected to each other, data cleaned up first, and money approved by somebody who has to say no to something else to fund it. Those are the constraints, and better prompting does not move any of them.

Impact tells you what to want, difficulty tells you what you can finish

If your organization has a technology department, sorting your list by impact is a perfectly sensible thing to do, because you employ people whose entire job is turning hard things into completed solutions.

Most nonprofits are not in that position. If you have between five and fifty staff and nobody whose job title contains the word technology, sorting by impact puts everything you cannot complete at the top of your list. You will spend your first three months there, build nothing, and reasonably conclude that this was all overstated.

That conclusion is wrong, and the experience that produced it is completely real. This is the failure mode I would most like to spare you.

So we re-sorted by difficulty and worked from the easy end.

What got built

Grant research

This is the one I would point to first. The workflow is unremarkable in description: before anyone writes an application, the AI reads the funder's guidelines, eligibility rules, exclusions, and FAQ.

I ran it this month across four different funding needs at once. It produced three applications genuinely worth starting, one renewal conversation that matters more than all three, and roughly a dozen phone calls that need making.

The most valuable thing it returned was a rule rather than a funder, and the rule is about our shape rather than our programs. We are a state office supporting 43 local affiliates. That makes us the wrong applicant for most of the funders a housing nonprofit would naturally approach, because place-based community foundations, county-gated corporate giving, and utility round-up funds all want their money to land inside one county. Our affiliates can promise that and we cannot. Chasing those funders also puts us in competition with the affiliates we exist to serve.

The funders that do fit are the ones where being statewide is the asset. Federal programs written for organizations that train and serve other nonprofits. Trade associations whose membership footprint is already the state. Manufacturers who would rather negotiate once than forty-three times.

Three cold foundation applications had gone nowhere before this, and the rule explains all three. That rule now lives in the file the workflow reads every time it runs, which means I get the benefit of having learned it without having to remember it.

Legislative research and evidence briefs

Part of my work is following what moves in the Michigan legislature and working out what it means for affordable housing in this state. The research is slow, the briefs have to be accurate, and both compete with everything else on the calendar. The tool does a first pass on the research and a first draft of the brief, and I check what it tells me about any bill against the bill itself, for the reasons Part 1 covers. What has changed most is how often the briefs actually get written.

The part that never makes it into a case study

Neither of those scaled until two unexciting things existed first.

We needed a written data policy so staff knew what they were allowed to put into the tool, which is what Part 2 was about. And we needed training, which turned into ten short recorded videos and a small first group working through them together, with our CEO in that group rather than watching from the sidelines.

Neither a policy nor a training program is an AI feature. Both had to exist before any of the AI mattered, and between them they took more of my time than every workflow on this list combined. If I were doing it again I would budget for that from the start.

Do this at your own organization

You do not need a formal audit. You need two questions and a few conversations.

Ask four or five people to walk you through a normal day. Write down every point where somebody moves information by hand from one place to another, retypes something that already exists somewhere, or compiles a document out of pieces.

Then score each item twice.

1. If this were fixed, how much would it help? High or medium is enough precision. You are ranking, not measuring.
2. What would it take to build? Be hard on yourself here. If your honest answer contains the phrase "we would need IT to," or "first we would have to clean up," or "that depends on the budget," it is not a low-difficulty item no matter how simple it sounds when you say it out loud.

Then start at the easy end, even though the easy end is the boring end. The goal in your first month is simply to finish something, because an organization that has completed three small things has a team that believes this works, and that team is what you need before you go anywhere near the hard four.

Part 3 ended with advice to score your opportunities by difficulty and start at the easy end. This part is about the thing that catches you out even when you do that, and it is the pattern behind the missteps I have made with AI this year.

All three below are mine and all three are recent. In all three the tool did exactly what I asked. What I got wrong was building it ahead of where the organization actually was.

The report with nothing to report

In May I built a daily summary of my own business numbers. Revenue, active clients, new conversations, subscribers, followers, all pulled together and waiting for me at six every morning.

Journey to Impact, the AI practice I run alongside the day job, has one client on a fixed monthly retainer. The revenue line is the same number every month by definition. New conversations were often zero, which was the accurate figure at the time. The report was accurate, and almost none of the numbers in it moved from one day to the next.

I turned it off in July, along with the collector behind it, and I will turn it back on when there is a CRM underneath it and enough happening to be worth reading. The build was maybe a day of work, which is a cheap lesson at that price. The version of this that worries me is the nonprofit signing a three-year contract for a reporting product before it has anything to report.

The easiest item on our list, which was not easy

The opportunity rated highest impact and lowest difficulty in our audit was a searchable place to keep our written procedures, so people stop asking the same three colleagues the same questions. I stand by that score. The tooling really is straightforward.

What the score does not capture is that a searchable library of procedures assumes you have written procedures, current enough to be worth searching.

I found this out sideways, while building something adjacent. I wanted a set of plain documents describing the organization so any of our staff could hand them to an AI tool and get answers that fit us rather than a generic nonprofit. The staff section had been written during our audit interviews in the spring. By the time I picked it up in August, two of the people named in it were no longer with the organization and one who had joined was not in it at all. The program structure I had written down was tidy on paper and did not match how the work is actually divided between people.

Building the search tool would have taken an afternoon. Getting to the point where it had something accurate to read is still going. That second thing is a documentation project, and it has never been anybody's priority because it has never been the most urgent thing in a given week.

The list that outran us

The third one is the audit itself.

Twenty-one opportunities came out of it. Twelve were rated high impact. Over the following months, working from the easy end as Part 3 described, we finished about four of them. The other seventeen are still sitting on the list.

I do not regret running the audit and I would run it again. What I would change is what I did with the output. A list of 21 items handed to a lean team with no technical staff functions as a backlog, and a backlog has a cost. Everyone can see the seventeen things not being done. I built a plan sized for an organization with more capacity than the one I actually work in.

The three, side by side

Each of these depended on something else already being in place, and in each case that thing was missing.

• A daily business metrics report
  AssumedEnough activity for the numbers to move. Was thereOne client on a fixed retainer, and months where new conversations were genuinely zero.
• A searchable library of our written procedures
  AssumedWritten procedures current enough to search. Was thereA staff section two departures out of date, and a program structure that did not match how the work is divided.
• A 21-item opportunity roadmap
  AssumedCapacity to work through 21 items. Was thereA lean team with no technical staff, which finished about four.

Why nonprofits run into this more than most

Starting with AI is cheap and quick. Building the foundations underneath it is slow, and that work is rarely funded. I have never seen a grant that pays for writing down how your programs work, and I have never been asked to present a documentation project at a board meeting.

There is also real pressure pointing the other way. A funder asks what you are doing with AI, a board member forwards an article, and the easiest thing to show either of them is a tool. Explaining that you spent two months getting your program records accurate is a harder conversation, even though it is the work that makes the tool function at all.

Lean teams also do not have anyone whose job includes keeping written things current. Staff change, program names and reporting requirements shift with grant cycles, and a good deal of how the organization runs lives in the heads of two or three long-tenured people and has never been written down anywhere. So the gap between what your documents say and what is true tends to open without anyone noticing, and it takes a while to close.

Four things I do differently now

1. Write down what it reads from, then confirm that thing exists and is current. This would have caught all three above.
2. If the answer contains "our procedures" or "our records," that is the project. The AI tool is the small piece at the end of it.
3. Confirm what your plan supports at the start, before you design around it.
4. Build the smallest version that runs on what you have today, instead of the version that would be right if the foundations were in place.

Documentation at a nonprofit never reaches a finished state, so the question of what this depends on and whether we have it is one to ask while you build rather than once at the beginning.