How-to Guides·7 min read·By Faz·Updated Aug 7, 2026

What to Ask an AI Vendor Before Donor Data Goes In (2026)

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.

Faz says: I review these tools for a living and the single most useful thing I have learned is that the quality of a vendor’s answer to an awkward question tells you more than any feature list. A good vendor answers precisely and volunteers the limitation. A weak one reassures you warmly and does not answer the question you asked. Ask, then notice which one you got.

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.

Saru says: Notice that only about half of these are security questions. The rest are honesty questions: does it cite sources, does it admit what it does not know, will it say all this in writing. That is deliberate. The likeliest harm to your organisation is not a dramatic breach, it is a fluent, confident, wrong statement about a donor acted on by a member of staff who had no way to check it.

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.

Frequently asked questions

How many nonprofits have an AI policy?

Around 24%. Roughly 76% have none, while 82% are already using AI informally, which is the gap this article exists to close.

Do we need a policy before we buy anything?

Ideally yes, and it is a small job given the free templates available. If tools are already in use, do both at once rather than pausing everything.

Is it safe to put donor data into a general-purpose AI assistant?

Not without checking the specific terms for your plan, which differ substantially between consumer and business tiers. Most nonprofit AI policies advise never entering donor records into any tool that has not been explicitly approved for that purpose.

What is retrieval before generation, in plain terms?

The system searches your actual records first and builds the answer from what it found, rather than producing plausible text from general knowledge. It is what makes an answer checkable, and it is the single most useful thing to ask about.

Should the board approve individual tools?

The board should approve the policy and review it annually. Individual tools sit with staff, using the questions above. Anything touching sensitive personal data or a large share of your file deserves a board mention.

What if a vendor will not answer in writing?

Treat that as the answer. Everything above is standard due diligence, and a vendor who finds it unreasonable is telling you something useful for free.

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.

Written by

Faz

Faz is the founder of AIToolsBakery. Every tool on this site is personally tested with real-world writing tasks before a single word gets published. Sponsored content is always clearly labelled.