A fundraising AI should answer faster than it acts
Evaluate an AI fundraising assistant with three permission levels: source-visible answers, complete previews, and separately confirmed live changes.
CharityStack
·4 min read
An AI fundraising assistant for nonprofits should have three permission levels: answer, prepare, and commit. Let it answer from named sources without changing data. Require a visible preview when it prepares a form, contact, payment, or message. Require a person to confirm the exact target and effect before it commits a live change.
That boundary should follow consequence, not how simple a request sounds. “Show me gifts from last month” and “create a payment for last month” differ by one verb, but only one changes the nonprofit's operating record.
Separate answers, preparation, and commits
An answer reads available information and returns an explanation, list, or chart. The response should name its source and time range so a staff member can inspect the same evidence. Jgive describes its assistant as reading charity data and answering without acting. This is the lowest-consequence mode, although sensitive data and incorrect answers still need appropriate controls.
Preparation creates something reviewable without making it live. That could be a draft appeal, a proposed contact, or a campaign form preview. Candid's current fundraising assistant can help find funders, check eligibility, and draft letters of inquiry using Candid data. The staff member receives work they can inspect rather than an unseen operational change.
A commit changes the live system: publishing a form, adding a contact, recording a payment, changing an amount, or sending a message. CharityStack's current product page says its fundraising assistant can answer questions and create forms, contacts, and payments by chat. That makes the action boundary a practical product question, not a theoretical AI debate.
These are evaluation categories, not claims about safeguards in any one product. Ask the vendor to show exactly where an answer ends, a preview begins, and a live change occurs.
Set the boundary by consequence
A blanket rule such as “a person reviews AI work” sounds safe but hides the important questions: reviews what, at which moment, with which evidence?
Use a stricter checkpoint as consequences rise:
- Answer: show the source records, filters, and time range beside the result.
- Prepare: show the complete proposed object, including fields the assistant inferred or left blank.
- Commit: show the named target, the exact change, who will be affected, and whether the action can be undone. Then ask for explicit confirmation.
The same verb can cross levels. “Create a campaign form” might mean drafting its fields, saving a private form, or publishing a donor-facing page. The assistant should not make the user guess which interpretation it chose.
NIST's human-AI interaction guidance says human roles and responsibilities should be clearly defined and differentiated. For a small nonprofit, the three modes turn that broad principle into questions a software demo can answer.
Run one campaign-form proof
Give every product the same bounded request: “Create a fall campaign form using our standard gift fields and last year's campaign as a reference.” Do not tell the presenter how to handle it. Observe the assistant's boundary.
A useful response unfolds in stages. First, it identifies the prior form and says which settings it plans to reuse. Next, it prepares a complete preview with the campaign name, designation, suggested amounts, required donor fields, receipt behavior, and public URL status. Finally, it asks whether to save privately or publish, while naming the exact form that will change.
Stop the proof if the assistant silently fills consequential gaps, treats “create” as permission to publish, or offers only a success message after acting. A polished result is less important than a visible decision boundary.
The donation-form test can check the finished donor experience. The CRM permission test helps verify which staff member should be allowed to approve higher-impact work. If the evaluation is part of a platform change, keep the same proof in the fundraising software migration plan.
Ask five questions in the demo
- Which requests only return an answer?
- Which requests create a private draft or preview?
- What information appears before a live commit?
- Can an administrator limit which people confirm payments, contacts, forms, or messages?
- Where can staff see what the assistant proposed and what a person approved?
A vendor may draw the line differently for each object. That is fine if the line is visible. The warning sign is not a narrow assistant or a capable one; it is an assistant whose authority changes without the user noticing.
The useful promise of fundraising AI is not that every instruction happens instantly. It is that routine questions move quickly while consequential work becomes easier to inspect. Let the assistant answer. Let it prepare. Make the live change a separate, named decision.