TL;DR
Nonprofit AI is only safe when donor PII is redacted before it enters any index, embedding, or third-party prompt; when tenant isolation is enforced architecturally rather than by policy; when no customer data is used to train any model; and when every AI interaction produces an audit record the nonprofit can export. Anything less is institutional risk dressed as productivity.
Why donor privacy is a different problem
Donor records carry categories of sensitive content that generic PII tools miss: health disclosures in gift notes, family hardship narratives, immigration status, faith affiliation, board relationships. Public guidance from sector bodies such as give.org and csnp.org has flagged that generative AI tools connected to nonprofit CRMs without a redaction layer expose this data to training corpora, vendor logs, and incidental disclosure in AI-generated content.
Privacy for donor data is therefore not the same problem as privacy for product analytics. It requires a different threat model, a different detection pipeline, and a different architectural commitment.
Four non-negotiable principles
Redact before storage, not before display
Detection must run before data enters any index, embedding, or LLM prompt. Query-time-only redaction leaves PII in places no UI ever shows.
Tenant isolation is architectural, not contractual
One nonprofit's data should be impossible to surface in another tenant's outputs — enforced by infrastructure, not by a policy document.
No customer data trains any model
Training-corpus exfiltration is the highest-impact threat. Eliminated by environment isolation and contractual no-training clauses on every LLM call.
Every AI interaction is auditable
Span-level detection records, redaction policy applied, model called, records retrieved — exportable by the nonprofit, not gated by the vendor.
Glossary of terms
Shared vocabulary for board reviews, vendor evaluations, and policy documents.
- PII (Personally Identifiable Information)
- Any data that can identify a donor on its own (name, email, phone, address, SSN, tax ID) or in combination with other fields (ZIP, employer, gift range, board role).
- PII Redaction
- The process of detecting and removing, masking, tokenizing, or generalizing personally identifiable information before it is stored, embedded, or sent to a third-party AI model.
- Write-time redaction
- Detection and redaction that runs before donor data enters any index, vector store, or LLM prompt. The standard required for defensible nonprofit AI.
- Query-time redaction
- Detection that runs only on AI output before it is displayed. Insufficient on its own because raw PII has already entered embeddings and vendor logs.
- Data isolation
- Architectural enforcement that one nonprofit's data cannot be used to train models, populate embeddings, or surface in outputs for any other tenant.
- Quasi-identifier
- A field that is not directly identifying on its own but uniquely identifies an individual when combined with others (e.g. ZIP + employer + gift range).
- No-retention endpoint
- An LLM API contract guaranteeing the vendor does not log, store, or use prompts and completions for model training or abuse monitoring.
- Audit trail
- Per-interaction record of which PII spans were detected, which redaction policy was applied, which model was called, and which records were retrieved.
The five threats a nonprofit AI tool must address
- Training-corpus exfiltration — donor data ingested into a third-party model's training set.
- Prompt-side leakage — PII in prompts logged or retained by the LLM vendor.
- Generation-side leakage — PII surfacing in AI outputs intended for public distribution.
- Vector store residue — un-redacted text in embeddings, which are invertible under attack.
- Re-identification via quasi-identifiers — individually innocuous fields combining to identify a donor.
Most off-the-shelf "AI for nonprofits" tools mitigate only the first two threats. The remaining three require write-time redaction and architectural isolation — the parts that are hard to retrofit.
Full threat model and detection pipeline in the technical whitepaper.
Frequently asked questions
What counts as donor PII in a nonprofit context?
Donor PII includes direct identifiers (name, email, phone, address, SSN, tax ID), financial PII (gift amounts tied to an individual, pledge balances, payment metadata), quasi-identifiers (DOB, employer, ZIP+4, household composition), nonprofit-specific sensitive data (health disclosures in gift notes, immigration status, program eligibility, family hardship narratives, faith affiliation), and relational PII (spouse names, board affiliations, advisor relationships). Generic PII libraries cover the first two categories; nonprofit-tuned detection is required for the rest.
Why is write-time PII redaction required for nonprofit AI?
Write-time redaction runs detection before donor data enters the index, vector store, or any LLM prompt. Query-time redaction (running detection only on AI output) leaves raw PII in embeddings, where it is demonstrably invertible under attack, and in third-party API logs. Only write-time enforcement eliminates prompt-side leakage and vector-store residue by construction.
Can AI tools train on our donor data?
Only if the architecture allows it. A defensible nonprofit AI system enforces data isolation at the infrastructure level — not via policy alone — so one nonprofit's data is never used to train models or surface in another tenant's outputs. Ask vendors to articulate whether isolation is contractual, logical, or physical, and whether third-party LLM calls hit no-retention endpoints.
What is the difference between tokenization, pseudonymization, generalization, and suppression?
Tokenization replaces PII with reversible tokens backed by a vault (preserves referential integrity). Pseudonymization replaces values with plausible synthetic ones (preserves prompt coherence for LLMs). Generalization replaces specific values with bucketed ranges (reduces re-identification on quasi-identifiers). Suppression removes the span entirely with [REDACTED] (maximum privacy, minimum utility). The right strategy depends on the downstream task.
What questions should a nonprofit ask an AI vendor about PII handling?
At minimum: (1) Does PII detection run at write-time, query-time, or both? (2) Which detection layers are in production — regex, NER, domain-tuned classifier, LLM guardrail? (3) Are nonprofit-specific PII categories covered? (4) What is stored in the vector store — raw or redacted text? (5) What no-retention guarantees exist on third-party LLM calls, and are they contractual? (6) Can the audit log be exported and queried without vendor mediation? (7) Is there a documented re-identification incident response procedure?
Is donor data shared between Gratefully customers?
No. Gratefully enforces tenant isolation at the database and embedding layer. One nonprofit's donor records, notes, embeddings, and audit logs are not accessible to any other tenant, and no customer data is used to train any model. Isolation is enforced architecturally, not by policy alone.
How does Gratefully handle PII when calling third-party AI models?
Donor data is redacted at write-time using a four-layer detection pipeline (regex, NER, nonprofit-tuned classifier, LLM guardrail) before it enters embeddings or prompts. Outbound LLM calls use pseudonymized payloads on no-retention endpoints. Every interaction produces an exportable span-level audit record.
What guidance has the nonprofit sector published on AI and donor privacy?
Sector bodies including give.org and csnp.org have flagged that nonprofits adopting generative AI without a PII redaction layer risk exposing donor data to training corpora, vendor logs, and incidental disclosure in AI-generated content. The mitigations require both contractual safeguards (no-retention endpoints, no-training clauses) and architectural ones (write-time redaction, tenant isolation, exportable audit trail).
How Gratefully implements this
A reference implementation
- Four-layer detection pipeline (regex → NER → nonprofit-tuned classifier → LLM guardrail) runs at write-time, before data is embedded or indexed.
- Tenant isolation enforced at the database and embedding layer — not just contractually.
- Outbound LLM calls use pseudonymized payloads on no-retention endpoints; no customer data trains any model.
- Per-interaction span-level audit trail, exportable by the nonprofit.
- Board-ready Safe AI Policy Pack documenting all of the above.
Related reading: Technical whitepaper · AI Data Security for Nonprofits · Gratefully vs ChatGPT
Gratefully · Donor privacy reference · Published May 25, 2026. Addresses concerns raised in public guidance from give.org and csnp.org regarding generative AI use with donor data.