Nonprofit AI Data Policy: Donor Trust Rules

A nonprofit AI data policy should define which information may enter an AI tool, who may approve that use, and how long the resulting copies may remain. Start with public or genuinely synthetic material. Treat identifiable donor records as a separate decision requiring a documented purpose, suitable provider terms, and accountable review.

The policy should cover staff, volunteers, contractors, and AI features inside tools the organization already uses. A ban on one chatbot does not answer what happens when a fundraising platform adds a drafting assistant or a browser extension can read an open donor record.

NIST’s AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into the design, development, use, and evaluation of AI systems. Its usefulness here is organizational: the nonprofit remains responsible for deciding how a tool fits its purpose and risks. It is not a seal of approval for a provider. NIST, AI Risk Management Framework

Educational disclaimer: This is defensive governance guidance, not legal advice, a retention schedule, or a statement that a particular privacy law applies. The suggested controls and hypothetical example are illustrative. Ask qualified counsel and relevant advisers to determine your actual obligations. Sources were accessed October 26, 2026.

Connect nonprofit AI data policy to donor expectations

A donor who provides information for a receipt has not necessarily agreed to every possible later use. Even where a use is legally permissible, leaders should ask whether it matches the relationship the organization has represented to supporters.

Begin with purpose, not the tool’s feature list. Is the proposed task drafting generic appeal language, summarizing public research, or analyzing individual giving histories? These activities use different information and require different decisions. A general authorization to use AI should not become an authorization to move the entire donor database.

NIST’s Privacy Framework is a voluntary tool for identifying and managing privacy risk while protecting individuals. This article uses that general risk-management approach, not the framework as a substitute for law. Its website also identifies a Privacy Framework 1.1 initial public draft; a draft should not be represented as an enacted requirement. NIST, Privacy Framework

For each proposed use, write a short explanation of the benefit, the information required, the people potentially affected, and what happens if the output or provider’s handling is unsuitable. If staff cannot explain why an identifiable field is needed, remove it from the proposed input.

Inventory data paths, including ordinary exports

A usable policy begins with an inventory of where donor information travels. Include the donor database, accounting records, spreadsheets, shared drives, email attachments, outsourced service providers, and locally downloaded campaign lists.

Add AI-related destinations to that map: prompts, attachments, saved conversations, generated outputs, integrations, support tickets, and shared workspaces. Ask about each provider’s actual settings and terms. Do not assume all services train on customer inputs, or that none do. Verify the particular service tier and configuration being considered.

Assign an owner for every approved tool. Record its intended use, permitted data categories, approved users, review date, and the person authorized to suspend access. A tool without an owner is not meaningfully governed merely because someone once purchased a subscription.

Use the inventory to distinguish a necessary institutional record from a convenience copy. An accounting record and a spreadsheet exported to draft a thank-you email may contain overlapping information, but their purposes and retention decisions need not be identical.

Set clear input boundaries staff can recognize

Avoid a policy that relies entirely on staff interpreting the word “confidential.” Provide recognizable examples and a route for uncertain cases. The following is an illustrative classification, not a universal legal taxonomy:

Proposed input	Starting policy position	Required next step
Published program description	Generally suitable for approved tools	Verify ownership and output accuracy
Fully invented donor scenario	Generally suitable if genuinely synthetic	Confirm it was not adapted from an identifiable person
Aggregate campaign totals	Review before use	Assess whether small groups reveal individuals
Donor names, contacts, or giving histories	Do not upload by default	Obtain purpose-specific privacy and provider review
Payment details or sensitive case notes	Exclude from ordinary drafting tools	Seek specialist assessment of any exceptional need

Removing a name alone is not enough to demonstrate that a record is anonymous. A distinctive gift, neighborhood, employer, or narrative may still make the person recognizable. Treat de-identification as a process to assess, not a label to apply casually.

For low-risk writing tasks, create reusable synthetic examples and approved public background material. This gives staff an efficient alternative to copying real records. The easier the approved path is, the less the policy depends on everyone improvising correctly under a campaign deadline.

Review providers before approving sensitive uses

NIST’s Generative AI Profile is a cross-sectoral companion to the AI Risk Management Framework, published in July 2024. It provides a dedicated reference for considering generative AI rather than treating it as an ordinary text editor. The profile is guidance, not a nonprofit-specific legal rule. NIST, Generative AI Profile

Turn provider review into questions that can be answered with written evidence:

• What inputs and outputs does the service retain, and for how long?
• Are inputs used for model training or another secondary purpose under this plan?
• Who can access saved conversations, uploaded files, and support records?
• What subprocessors or integrations receive information?
• What does deletion remove, and what remains in backups or logs?
• How are changed terms, incidents, and account closure handled?
• Can the nonprofit restrict sharing and remove access when people leave?

Retain the relevant contract or terms version, configuration evidence, reviewer, and approval date. Do not treat a marketing phrase such as “enterprise privacy” as the answer to all seven questions.

If a provider cannot answer a question necessary to the proposed sensitive use, limit the use or choose another approach. The policy can approve generic drafting while withholding approval for identifiable donor analysis. Approval should be scoped, not binary and permanent.

Make retention a documented lifecycle decision

Do not invent one retention period for all donor-related information. Determine the purpose and applicable requirements for each record category with appropriate advisers. Consider contracts, tax and accounting needs, dispute handling, donor preferences, and any preservation instruction before deciding on disposal.

Then address temporary copies separately. Define when an export expires, who removes it, and whether generated summaries belong in the official record. Give draft appeal files a named owner rather than leaving them indefinitely in personal folders.

An illustrative retention register can include these columns:

Register field	Management question it answers
Record category and purpose	Why is this information retained?
Official system and duplicate locations	Which copy is authoritative?
Approved retention trigger	When does the review or disposal clock begin?
Preservation exception	What pauses normal disposal?
Disposal owner and method	Who completes and records the action?
Provider limitations	What deletion cannot yet be confirmed?

Distinguish a deletion request from proof of deletion. Ask providers to explain what their process covers and how retained backups are handled. Communicate accurately about any limitations. Do not promise supporters immediate erasure everywhere unless the organization can support that promise.

Keep donor preferences available without keeping everything

A request not to receive future appeals may require a carefully limited suppression record so the organization does not accidentally reimport and contact that person. Decide what minimal information is needed and restrict its use. Do not assume that deleting every trace automatically honors the preference.

Similarly, preserve records that are legitimately required while removing unnecessary working copies when appropriate. A well-governed lifecycle is not indiscriminate deletion; it is an explained choice about purpose, access, duration, and disposal.

Require human review of outputs and consequences

An approved tool can still produce an unsuitable result. Assign a human reviewer for facts, tone, donor preferences, and unintended disclosure before an output becomes a communication or operational decision.

Do not let a generated summary become the unquestioned authority on a donor’s wishes. Confirm against the authorized record. Review segment descriptions for unfair assumptions, and avoid treating inferred personal circumstances as established facts.

Define activities the organization will not delegate automatically, such as final decisions about eligibility for sensitive services or publication of personal donor stories. The exact boundary depends on the mission. The important control is to make it explicit before a convenience feature starts influencing decisions unnoticed.

Hypothetical example: a year-end appeal draft

A development coordinator wants an assistant to draft tailored appeals using a spreadsheet containing names, addresses, gift amounts, and notes about personal circumstances. This is an invented training scenario, not an account of a real nonprofit.

The approved policy allows generic drafting but not uploading identifiable donor spreadsheets. The coordinator instead uses synthetic supporter profiles and public program descriptions. A staff reviewer checks the resulting language, and authorized staff apply donor preferences within the organization’s approved workflow.

The team also discovers old campaign exports in a shared folder. It inventories those copies, checks for preservation requirements, and schedules appropriate review and disposal. The lesson is broader than avoiding one upload: the drafting request exposed a lifecycle gap that management can now address.

Give the board evidence rather than assurances

Report approved uses, unresolved provider questions, staff training completion, overdue retention reviews, and policy exceptions. Include an owner and due date for each issue. A report stating “AI is secure” does not explain what the organization has actually authorized.

Align this discussion with the financial and governance reports your board receives. For organizational context, what your Form 990 says about you discusses how public reporting contributes to confidence; an AI policy should likewise be something leaders can explain accurately, not merely check off.

Start with a short implementation checklist:

• Name the policy owner and a review date.
• Inventory active AI tools and donor-data exports.
• Publish permitted, restricted, and prohibited input examples.
• Document provider evidence for each approved use.
• Set output-review and exception responsibilities.
• Link temporary-copy disposal to the retention register.
• Offer a supportive channel for reporting accidental uploads.

If information is uploaded outside policy, preserve relevant evidence and escalate promptly to the designated privacy, legal, and security advisers. Establish facts before making promises about removal or notifications. A credible donor-trust program makes room for reporting mistakes and correcting the process that allowed them.

Sources

• National Institute of Standards and Technology: AI Risk Management Framework, overview of the voluntary framework released January 26, 2023. Accessed October 26, 2026. No later revision or legal effect is assumed.
• National Institute of Standards and Technology: Privacy Framework, overview and draft-status information. Accessed October 26, 2026. The cited draft is not presented as final or legally binding.
• National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 26, 2024. Accessed October 26, 2026.