There is no shortage of nonprofit AI policy templates. There are free ones from sector bodies, generators that draft one in twenty minutes, and board-ready packs from vendors. If you need a policy document, you can have one this afternoon.
Which makes it strange that 76% of nonprofits still do not have an AI policy, while 82% are already using AI informally. The gap is not caused by a shortage of templates.
It is caused by the fact that a policy tells your staff what they may do, and says almost nothing about whether the specific tool they are about to connect to your donor database is safe. That is a procurement question, and nobody has written the procurement half.
This is the procurement half: the questions to ask an AI vendor before donor records go anywhere near it, what a good answer sounds like, and what should end the conversation.
Quick answer: A policy governs your staff. Vendor due diligence governs your data. Ask about tenant isolation, whether your data trains their models, where answers come from, PII handling, audit trail, deletion, subprocessors and breach notification. Get the answers in writing before any donor record is connected.
Why the template is not enough
A policy typically covers four areas: governance, data privacy, risk management and ethics. It will tell staff not to paste donor records into unapproved tools, which is sensible and necessary.
But the operative word is unapproved. The policy assumes someone did the approving. In most nonprofits nobody has, because nobody knows what to ask, so approval means a director said yes to a demo.
The questions below are what approval should actually mean. You do not need technical expertise to ask them. You need the answers in writing, because a vendor that will not put an answer in writing has given you your answer.
The fifteen questions
On isolation and training
1. Is our data in an isolated tenant, or pooled with other customers?
Good answer: a specific architectural description. Weak answer: “your data is secure”.
2. Does our data train your models, or any third-party model?
This is the question. Get an unambiguous no, in writing, covering both the vendor’s own models and any underlying providers. A vendor saying data may be used to “improve the service” has not said no.
3. Which third-party AI providers sit behind your product, and what are their terms?
Most products are built on someone else’s models. Your data governance is only as strong as theirs. A vendor unwilling to name their providers is asking you to accept an unnamed subprocessor.
4. Can we opt out of any data use beyond serving us?
If the answer is that no such use exists, good. If it does exist, opting out should not be conditional on an enterprise plan.
On how answers are produced
5. Where do answers come from: our records, or the model’s general knowledge?
This is the difference between a tool that reports and a tool that speculates. The pattern you want is retrieval before generation, where the system finds the relevant records first and produces an answer from them, rather than generating fluent text that may or may not reflect your data.
6. Does every answer cite its source?
If a tool tells your major gifts officer that a donor’s capacity has increased, they need to know whether that came from a note in the file or from a plausible-sounding inference. Citation makes the difference checkable.
7. What does it do when it does not know?
Ask them to demonstrate this in the demo. A system that abstains is safer than one that always produces something. Confident fabrication about a donor is the failure mode that ends relationships.
On personal data
8. How is personally identifiable information handled and redacted?
Donor PII covers names, addresses, payment details, and often far more sensitive material sitting in contact reports. Ask specifically whether PII can be redacted before anything is shared or exported.
9. Where is data stored, and in which jurisdiction?
Relevant for GDPR, for grant conditions, and increasingly for institutional funders who ask.
10. Is there a full audit trail?
Who accessed which donor record, when, and what the system did. This matters for internal trust as much as compliance, and it is the thing that makes staff comfortable rather than surveilled.
On exit and failure
11. If we leave, what happens to our data and on what timeline?
Ask for the deletion timeline in writing, including backups. “We delete on request” without a timeline is not an answer.
12. Can we export everything, in a usable format?
Including anything the system generated on top of your data.
13. What is your breach notification commitment?
A specific number of hours. If they have not thought about it, they have not thought about breaches.
14. What is your track record and who is behind the company?
Not a security question exactly, but a real one. Early-stage vendors in this category are common and a short track record is a genuine risk factor to weigh, not a disqualifier.
15. Will you answer all of the above in writing for our board?
The one that saves you the most time. A vendor comfortable with everything above will do this readily.
What a good answer set looks like
To make this concrete rather than abstract, here is how one vendor in this category answers publicly. We are using Gratefully as the worked example because its documentation is unusually specific, not because it is the only acceptable answer, and everything below is a vendor claim that you should verify in your own procurement rather than take from us.
- Isolation: “Isolated tenant. Never shared.”
- Training: donor data does not train public AI models.
- How answers are produced: “Retrieval before generation. No hallucinations”, with every answer showing its source, described as “never the open web, only your records”.
- PII: automated detection with one-click redaction for anything shared externally.
- Audit: full audit trail with PII detection.
That is roughly what a strong answer set looks like: specific, architectural, and stated in public rather than only in a sales call. Compare whatever you are evaluating against it. Our Gratefully review covers the product itself, including its limitations, and we have not verified these security claims independently.
The three answers that should stop the conversation
“Your data may be used to improve our models.” Unless you can opt out, in writing, at no extra cost.
“We can’t disclose our subprocessors.” You cannot govern what you cannot see, and your funders may ask.
Vagueness under direct questioning. If you ask where answers come from and receive reassurance rather than an explanation, you have learned that either they do not know or they would rather you did not.
What to do internally, in order
- Inventory what is already happening. Given 82% informal usage, staff are already using tools. Find out which, without blame, or your policy will govern a fiction.
- Classify your data. Donor PII, financial detail, and sensitive contact-report material need different handling from your public case for support.
- Adopt a policy. Use one of the free templates. This is genuinely the easy step and there is no need to write one from scratch.
- Add procurement questions to it. This is the part templates miss, and it is what this article is for.
- Approve tools individually, in writing. Approval means the questions were asked and the answers were acceptable.
- Take it to the board once a year. Policies should be reviewed annually, and board members should be participants rather than recipients.
- Train people. A policy nobody has read governs nothing.
The governance questions that decide whether this is safe, not just whether it works
Donor data is among the most sensitive a small organisation holds: names, addresses, giving capacity, sometimes health or family circumstances captured in a contact report. Four areas decide your exposure, and all four are answerable in writing before anything connects.
Training, which is the question most often answered vaguely
Ask directly whether your data is used to train or improve any model, including in aggregated or anonymised form, and whether that applies to subprocessors as well as the vendor. “We do not train on customer data” and “we do not train foundation models on customer data” are different sentences and the second leaves room for a great deal. Get the answer as a contract term, not a sales assurance, because only one of those survives a change of ownership.
Subprocessors, and the ones behind the one you are buying
Most tools in this category are built on a model provider they did not write. Ask for the current subprocessor list, where each one processes data geographically, and how you are notified when it changes. A vendor that cannot produce this list in a day does not have it, which tells you what you need to know about the rest of their programme.
Retention and deletion, stated in days
Ask how long prompts, outputs and uploaded records are retained, whether retention differs for logs and support tickets, and what deletion actually means: removed from live systems, removed from backups, or flagged. Then ask for the deletion timeline in days. A vendor that will commit to a number in the contract is a different proposition from one that describes a process.
Individual rights, which are yours to honour and theirs to enable
If a donor asks what you hold on them, or asks you to delete it, you are the one who has to answer. Ask how the vendor supports a subject access request or an erasure request, how long it takes, and whether inferences the tool generated about that person are included. Inferred capacity ratings and propensity scores are data about a person even though the person never supplied them, and a tool that cannot surface or delete them puts the obligation back on you with no way to meet it.
The three answers that should end the conversation
A refusal to put the training answer in writing. An inability to name the subprocessors. And a claim that the model cannot be wrong, or that its outputs need no human review before a gift officer acts on them. The first two are governance failures you can see from outside; the third is a vendor telling you they do not understand their own product, and it is the most reliable single signal in the category.
What donor data actually looks like when a vendor first connects to it
Vendor readiness checklists describe a database nobody has. Here is what the connection usually finds, and which of it genuinely matters.
History that predates the current database
Most organisations have migrated CRM at least once, and migrations lose things quietly. Gifts before the switch often arrive as a single opening balance rather than individual transactions, which means a model reading “first gift date” gets the migration date, not the truth. Check one long-standing donor manually before believing any recency analysis. If the earliest gift for a forty-year supporter is dated 2019, you have found a migration boundary and every recency score in the system is measuring the wrong thing.
Soft credits, which break attribution in both directions
A gift from a donor-advised fund, a family foundation or a matching employer arrives from one legal entity while the relationship belongs to another. Whether your database records the individual, the vehicle, or both with a soft credit determines whether a model sees a lapsed donor or an active one. This is the single most common cause of a prediction that looks obviously wrong to a gift officer, and it is a data structure problem rather than a model problem.
Households, which most systems handle badly
Two people, one gift, one address, sometimes two records, sometimes one. Ask what a tool does with household relationships before it runs anything, because deduplicating a couple into one record destroys the individual giving history and leaving them separate double counts your donor numbers. Neither answer is wrong; you need to know which one you have.
Coding that changed meaning without changing name
Campaign and appeal codes get reused. A fund code that meant one programme in 2021 and another in 2024 is worse than a missing code, because it is confidently wrong and nothing flags it. Before connecting anything, pull the list of codes used in the last five years and have the person who has been there longest read it. That single hour finds more real problems than any automated data quality report.
Contact reports that record attendance, not content
“Coffee with donor, went well” is a diary entry. It tells a tool that contact happened and nothing about what was said, what was asked for, or what the donor cares about. Systems that read notes are only as good as the notes, and most organisations have years of attendance records rather than substance. This one is fixable going forward and unfixable backwards, which argues for changing the note template today regardless of whether you buy anything.
What none of this blocks
Imperfect data is not a reason to wait. Duplicates, gaps and inconsistent coding are the normal condition of a fundraising database and every vendor in the category has seen worse than yours. What genuinely blocks a deployment is different and much narrower: no export route, no owner, or no agreement about what the output is for. Fix those three and start; fix the coding as you go.
Where the figures on this page come from
Every price quoted here was read from the vendor’s own pricing page on 4 September 2026, not from an aggregator or a review site. That distinction matters more in this category than in most, because nonprofit software pricing changed materially over the past year and a great deal of what circulates online describes packaging that no longer exists.
The pages we read
Little Green Light publishes every constituent band from $45 a month. Salesforce Nonprofit Cloud publishes $60 per user per month with ten licences free under Power of Us. Bloomerang publishes $125 a month for the CRM with other products priced separately. Keela publishes every contact band from $164 a month. Dataro publishes $15,000 a year plus ten cents per active donor on a page that is not linked from its own navigation. Blackbaud and Virtuous publish no figures at all.
What we do not do
We do not carry a figure we cannot source to the vendor. Where a number circulates widely and cannot be traced to a vendor page, we say so and withdraw it rather than repeating it with a hedge, and we have withdrawn our own published figures on that basis more than once. Where a vendor confirms an unpublished price directly to us, it is attributed as confirmed by the company rather than presented as a public rate.
Why every figure carries a date
Keela raised every band by roughly 15 to 22% in under two weeks in late August 2026. Neon retired an entire tier structure. A pricing claim without a verification date is not checkable, and in this market it is usually wrong within a year.
The bottom line
Adopt a policy, because they are free and you should have one. Then do the part the templates leave out, which is asking the vendor the questions that determine whether your donor data is actually safe with them.
The answers matter less than the shape of the answers. Specific, architectural and in writing is good. Warm, reassuring and imprecise is not, and it is the most common thing you will encounter.
Your donors gave you their money and their information. The second one is the harder trust to earn back.
Related: donor data privacy in AI fundraising, is your donor data ready for AI and new CRM or better intelligence.
Written by
FazFaz is the founder of AIToolsBakery. Some tools here are tested hands on. Others are assessed from vendor documentation and pricing verified on the live page, and every review says which one it is. Sponsors can buy a position in a guide. They cannot buy the score, the criticism, or silence about a better option.
How we test and how we make money →Frequently Asked Questions
