Nonprofit AI Data Security: What to Ask Before Connecting Donor Data
The distinction that matters is whether a contract exists, not which company makes the tool. Ask where personal data is removed: before indexing is a real control, at output is cosmetic. Then check your own donor privacy policy, which is the step most organizations skip.
The question every nonprofit board is now asking is some version of: if we let this thing read our donor database, where does the data go? It is the right question, and the answers vendors give are frequently designed to sound reassuring without committing to anything.
This page sets out what to ask, what the answers mean, and which distinctions actually matter. It is written for the person who has to explain the decision to a board, not for a security engineer.
The one distinction that matters most
Not which company makes the tool. Whether there is a contract.
| Consumer account | Contracted tool | |
|---|---|---|
| Agreement with your organization | None | Yes |
| Commitment on training with your data | Varies, changeable | Contractual |
| Who can see it internally | Not specified to you | Documented |
| Retention and deletion | Vendor’s discretion | Stated period |
| Suitable for donor records | No | If the answers below check out |
The same company can offer both. A free personal account and a business tier of the identical product are different propositions, because only one of them creates obligations to you.
The practical rule that fits on a sticker: if you would not put it in an email to a stranger, it does not go into a tool you have no agreement with.
What “we do not train on your data” actually means
This is the most common assurance and the least examined. Three questions turn it into something meaningful.
Does it cover the subprocessors? Most nonprofit AI products do not run their own models. They send requests to a third party. The vendor’s promise is worth what their agreement with that third party is worth, so ask which providers are used and on what terms. The answer you want is that outbound calls go to no-retention endpoints.
Does it cover improvement as well as training? Training a public model and reviewing your data to improve a service are different activities, and a commitment against the first does not always exclude the second.
Is it in the contract or on the marketing page? Marketing pages change without notice. Contracts do not.
Redaction: at write time, or at output
This is the technical distinction that separates serious products from the rest, and almost nobody outside the industry knows to ask about it.
| Approach | What happens | Worth |
|---|---|---|
| Output filtering | Personal data is removed from what you see, after processing | Cosmetic. The system already ingested and indexed it. |
| Write time redaction | Identifiers are removed before anything reaches an index, an embedding or a prompt | A real control |
Ask specifically at which point in the pipeline personal data is removed. A vendor doing this properly will answer precisely, because it is expensive to build and they will want credit for it. Gratefully, for example, publishes a four layer approach applied before indexing, using pattern matching, entity recognition, a sector tuned classifier and a final model check, with pseudonymised payloads sent to no-retention endpoints. Whether or not you buy it, that is the shape of an answer that means something, and it is a fair benchmark to hold others to.
A vendor who cannot say where redaction happens is telling you it happens at the end, or not at all.
The nine questions
Ask in writing. A vendor unwilling to answer in writing has answered.
| Question | Acceptable answer |
|---|---|
| Is our data used to train models, and can we opt out | No, or a documented opt out |
| Is our data isolated from other customers | Yes, per tenant |
| Where is it stored and processed | A named location |
| Which subprocessors see it | A named list, with terms |
| At what point is personal data removed | Before indexing, not at output |
| Who at the vendor can access our instance, and when | Documented, and logged |
| Can we export everything, in what format | Yes |
| What is retained after cancellation, for how long | A stated period |
| Is there an independent audit, such as SOC 2 | Yes, or a stated timeline |
On the last one, be realistic. Much of the nonprofit AI category is young and independent certification is not yet universal, including among products that are otherwise careful. A stated timeline is a reasonable answer. No answer is not, and neither is a detailed technical description offered in place of one. Documented controls and audited controls are different things, and a board is entitled to know which it is being given.
Your own obligations, which people forget
Before connecting anything, check what you have already promised.
Your donor privacy policy. If it tells donors their information is not shared outside the organization, connecting any third party tool requires you to look at that sentence first. This is the most commonly overlooked item on the list.
Grant agreements. Some restrict how data collected under the grant may be processed or where it may be stored.
State charitable registration. Requirements vary and some states impose specific obligations around donor information.
Sector specific rules. Health information, student records and safeguarding data carry their own regimes and generally should not go near a general purpose tool at all.
Sensitive data in a nonprofit is not what people expect
Commercial guidance about personal data focuses on names, addresses and card numbers. Nonprofit records contain a different and often more sensitive category, usually sitting in free text fields nobody thinks of as data.
Gift notes carry health disclosures, bereavements, family hardship, immigration status, faith affiliation and programme eligibility. A note reading “gave after her son’s treatment, do not mention the hospital” is more sensitive than a card number and considerably harder to redact automatically.
Classify these as your highest tier and keep them out of general purpose tools entirely. Our AI use policy template includes a four level classification table built around exactly this.
If something has already gone in
Assume it has. In an organization of any size, somebody has pasted something into a chatbot to get a job done, and they did not think of it as a data disclosure.
Handle it as a process problem rather than a disciplinary one. Establish what was entered, into which tool and on whose account. Check that vendor’s stated position on retention and training for that account type, and use any available control to delete the conversation history and opt out of training. Then record it.
Whether it is reportable depends on what the information was and what you have promised. A draft newsletter is not an incident. Donor names with giving histories, or anything about a service user, may well be, and that judgement should involve whoever handles your data obligations rather than being made by the person who did it.
The reason to keep reporting blameless is arithmetic. Staff who expect a disciplinary response will not tell you, and you will find out from somewhere else, later, when the options are worse.
What to do first
Three things, in order, and only the third costs money.
Adopt a policy, so people know which tools may be used for what. Forty seven percent of nonprofits have none, and this is where most incidents actually originate.
Inventory what is already in use, including AI features switched on inside software you already run. Meeting transcription, email summarisation and CRM scoring arrive without anyone deciding to adopt them.
Then assess anything you are considering connecting to donor records, using the nine questions. If you are at that stage, we cover what the category does and what it costs in AI tools for nonprofit fundraising.
Questions people ask
Is it safe to connect AI to our donor database?
It can be, with a contracted tool and the right answers in writing. It is not safe with a consumer account, and that distinction matters more than which company makes the product.
Establish four things before connecting anything: your data is not used to train models, it is isolated from other customers, personal data is removed before indexing rather than only at output, and you can export everything and know what is deleted after cancellation.
Then check your own donor privacy policy. If it promises donors their information is not shared outside the organization, that sentence governs before any vendor assurance does.
What does write time redaction mean?
Personal identifiers are stripped out before the data reaches any index, embedding or model prompt, rather than being filtered out of the answer afterwards.
The difference is substantive. Output filtering is cosmetic, because the system has already ingested and stored the personal data. Write time redaction means the identifiers were never in the processing pipeline at all.
Ask vendors at which point in the pipeline redaction happens. A vendor that has built this properly will answer precisely. One that cannot is telling you it happens at the end, or not at all.
Should we require SOC 2 from an AI vendor?
Ask for it, and be realistic about the answer. Much of the nonprofit AI category is young and independent certification is not yet universal, including among products that handle data carefully in other respects.
A stated timeline is a reasonable answer for a young product. A detailed technical description offered instead of an answer is not, because documented controls and independently audited controls are different things.
Record which one you were given, and tell the board. If a product is otherwise a good fit and has no certification, that is a decision a board can take knowingly. It is not one that should be taken by omission.
Can we use ChatGPT with donor data?
Not on a free or personal account. There is no agreement between the vendor and your organization, so you cannot tell a donor or a board what happened to their information.
Business tiers with a contract are a different question and may be acceptable, depending on the answers to the nine questions and what your own privacy policy promises.
For work involving no personal data, consumer tools are fine and genuinely useful. Drafting appeals, rewriting newsletters and summarising funder guidelines are the bulk of the realistic benefit and none of it requires donor records.
What counts as sensitive data in a nonprofit?
More than most guidance assumes, and it usually sits in free text fields nobody thinks of as data.
Gift notes and case notes routinely contain health disclosures, bereavements, financial hardship, immigration status, faith affiliation and programme eligibility. A note explaining that a donor gave after a family illness is more sensitive than a card number and much harder to redact automatically.
Treat these as your highest classification and keep them out of general purpose tools entirely. Also treat anything concerning a child, a service user or a safeguarding matter as off limits without specific written approval.
Does our donor privacy policy affect this?
Very likely, and it is the item organizations most often overlook.
Many nonprofit privacy policies contain a promise that donor information is not shared with or sold to third parties. Connecting a donor database to an external AI platform is a disclosure to a third party, whatever the security arrangements around it.
Read your published policy before connecting anything. You may need to update it, which is a legitimate thing to do, or you may need a different approach. What you should not do is connect the system and hope nobody reads the policy back to you.
What about AI features in software we already use?
This is the most likely route by which data reaches a system nobody assessed, and most policies miss it entirely.
Meeting transcription, email summarisation, drafting assistants and CRM scoring arrive as features inside products you already approved. Nobody signs up for them and nobody thinks of it as adopting an AI tool, so they never enter a register that lists only products someone chose.
Define AI tools in your policy to include features inside existing software, and review what has changed in your current stack rather than only what has been added.
Who should approve AI tools at a nonprofit?
The board sets the policy and approves the framework. A named staff member owns the register of approved tools and makes individual approvals within it.
Without a named owner the register goes stale within months and the policy becomes a document rather than a control. In a small organization this is usually the executive director.
Keep incident reporting blameless and separate from discipline. A policy that punishes people for admitting mistakes guarantees you hear about problems late, which is exactly when they become expensive.
This is reference information, not legal or tax advice. Rules vary by state and change over time. For a decision that carries real consequences, check the current text at irs.gov or your state registry, and talk to a nonprofit attorney or CPA.