Quick answer
AI PII redaction is the process of detecting and removing personally identifiable information from donor data before it reaches an AI tool, not after. For nonprofits, the only safe pattern is write-time redaction: PII is stripped before data is embedded, indexed, or sent to any model. This paper specifies the detection pipeline, redaction strategies, and architecture that decide whether donor PII actually stays private.
Abstract
Public guidance from sector bodies including the BBB Wise Giving Alliance (give.org) and CyberSecurity Nonprofit (csnp.org) has correctly flagged that nonprofits adopting generative AI without a PII redaction layer expose donor data to training corpora, vendor logs, and incidental disclosure in generated content. The scale is real: a 2026 Virtuous and Fundraising.AI report found 92% of nonprofits now use AI tools, while 76% have no AI governance policy in place. Donors notice. In the BBB Give.org Donor Trust Report, data and privacy considerations were "somewhat" or "very" important to the large majority of donors when deciding whether to give.
This paper specifies the technical safeguards required to address those concerns: a four-layer detection pipeline, a strategy-appropriate redaction policy, write-time enforcement, and a verifiable audit trail. It is written for nonprofit operations leaders, IT staff evaluating AI vendors, and board members reviewing AI policy, not for ML researchers. The goal is to translate sector concerns into concrete questions a nonprofit can answer about any AI tool before connecting it to a donor database.
1. Threat model
PII redaction is not a single problem. The right mitigation depends on which threat is being addressed.
T1 — Training-corpus exfiltration
Donor data ingested into a third-party model's training set, where fragments later surface in unrelated users' outputs. Mitigated by data-isolation contracts AND architectural enforcement (no shared training environment), not by policy promises alone.
T2 — Prompt-side leakage
PII included in prompts sent to a third-party LLM API, where it is logged by the vendor or retained for abuse monitoring. This is not hypothetical: OpenAI, for example, does not train on API data by default but retains API inputs and outputs for up to 30 days to monitor for abuse. The tool tier matters here. Free consumer ChatGPT may train on conversations unless a user opts out; the API and Business/Enterprise tiers do not train by default but still retain inputs for that 30-day window. In other words, "we don't train on your data" is not the same as "your data never leaves your control." Mitigated by pre-prompt redaction at write time, not at display time.
T3 — Generation-side leakage
PII surfacing in AI-generated content intended for public distribution (newsletters, grant reports, social posts). Mitigated by output-side scanning before content is released.
T4 — Vector-store residue
Embeddings derived from un-redacted text. Embeddings are not human-readable, but they are demonstrably invertible. In a 2023 study, Morris et al. reconstructed 92% of 32-token text inputs exactly from their embeddings alone, with no access to the source model. An attacker with read access to your vector store can recover donor PII from embeddings even if the text was never displayed. Mitigated by redacting before embedding, never after.
T5 — Re-identification via quasi-identifiers
Individually innocuous fields (ZIP, employer, gift range, board affiliation) combining to uniquely identify a donor. Mitigated by generalization, not suppression.
2. PII categories for nonprofit data
Generic PII libraries cover direct identifiers and financial PII reasonably well. They systematically miss two categories that dominate nonprofit free-text fields.
| Category | Examples |
|---|---|
| Direct identifiers | Full name, email, phone, mailing address, SSN, tax ID |
| Financial PII | Gift amounts tied to an individual, pledge balances, payment-instrument metadata |
| Quasi-identifiers | DOB, employer, ZIP+4, household composition (re-identifying when combined) |
| Nonprofit-specific sensitive | Health disclosures in gift notes, immigration status, program eligibility, family-hardship narratives, faith affiliation |
| Relational PII | Spouse names, board affiliations, advisor relationships captured in free text |
The last two rows are where off-the-shelf redaction fails. A development database is full of sentences like "Margaret's husband is on dialysis, so she asked us to pause solicitations," text that no generic PII model is tuned to catch. The U.S. government's own definition of PII, in NIST Special Publication 800-122, explicitly includes information that is "linkable" to an individual, which is exactly what these free-text fields are.
As a working rule, none of the data in this table should ever be pasted into a consumer AI tool, alongside board minutes, financials, and privileged communications. That single habit removes the most common leak. Sector guidance such as The Nonprofit Alliance's AI usage policy considerations makes the same point: decide what data is allowed in which tools, and strip PII before anything reaches an AI system.
3. Decision flow: can this data go into an AI tool?
Before any donor data reaches an AI tool, route it through three questions.
- Does the data identify a person or their giving? Names, contact details, gift amounts, and the sensitive free text in donor notes all count. If it does not (an aggregate trend or a fully anonymized figure), it is safe to use even in a consumer tool.
- If it does, is the tool a free or consumer AI tool? If so, do not paste it. Redact first, or move the work to an approved tool.
- If the tool is a Business, Enterprise, or API tier, does a write-time redaction layer strip PII before the data is stored, embedded, or sent? If yes, it is safe to use. If no, redact first or treat it as unsafe.
Three outcomes: safe to use, redact first, or never. When in doubt, redact.
4. Four-layer detection pipeline
No single detection technique is sufficient. A defensible pipeline composes deterministic rules, statistical NER, domain classifiers, and a contextual guardrail.
Layer 1 — Deterministic pattern matching
Regex and validated checksums for structured PII: emails, phone numbers (E.164), credit-card numbers (Luhn), routing numbers, SSN/EIN patterns, IP addresses. Highest precision, lowest recall. Catches the obvious, misses anything contextual.
Layer 2 — Named Entity Recognition (NER)
Transformer-based NER models (typically fine-tuned BERT or RoBERTa derivatives) classify spans as PERSON, ORG, LOC, MONEY, DATE. Required to catch unstructured PII in donor notes where regex cannot reach. Output is span-level: start offset, end offset, entity type, confidence.
Layer 3 — Domain-tuned classifiers
Nonprofit-specific categories (health mentions, immigration status, family hardship) require fine-tuning on annotated nonprofit text. Generic PII libraries (Presidio, AWS Comprehend, GCP DLP) miss these by default. This is where most off-the-shelf redaction fails for nonprofit data.
Layer 4 — LLM-based contextual review
A guardrail model reviews ambiguous spans before the redaction decision is committed. Used only as a tie-breaker, never as the primary detector: LLM-only PII detection is non-deterministic and misses a meaningful share of entities in long-form text, so it cannot be trusted as the sole line of defense.
Layers compose. Each layer's output is a set of span proposals; the final policy decides which spans to redact and how.
5. Redaction strategies
Detection identifies what is PII. Redaction decides what to do with it. The right strategy depends on the downstream task.
| Strategy | What it does | When to use |
|---|---|---|
| Tokenization | Replace PII with reversible tokens (e.g. <PERSON_07A3>) backed by a vault. Preserves referential integrity across documents. | When downstream analytics depend on cross-document linking (the same donor stays the same token). |
| Pseudonymization | Replace with plausible synthetic values (e.g. Margaret → Susan). | LLM prompts where the model needs realistic text to generate coherent output. |
| Generalization | Replace specific values with bucketed ranges (a gift of $14,500 → "$10K to $25K range"). | Reducing re-identification risk on quasi-identifiers (T5). |
| Suppression | Remove the span entirely, replace with [REDACTED]. Highest privacy, lowest utility. | When the field is irrelevant to the downstream task. |
6. Write-time enforcement is non-negotiable
The most consequential architectural decision in a PII redaction system is when detection runs. Two patterns dominate.
Query-time redaction. Raw PII is indexed; detection runs on each output before display. Easy to retrofit. Fails the embeddings test (T4) and the vendor-logging test (T2), because PII has already entered the searchable system and any third-party API logs.
Write-time redaction. Detection runs before data enters the index, the vector store, or any LLM prompt. Harder to implement, because it requires a stable detection pipeline before ingestion. Eliminates T2 and T4 by construction.
A vendor that cannot articulate which pattern they use should be assumed to use query-time. Ask: "At what point in your ingestion pipeline does PII detection run, and what is stored before that point?"
Common failure mode
A vendor stores raw donor records, embeds them for semantic search, and only runs PII detection on rendered chat responses. The embeddings now encode PII; per the inversion research in T4, an attacker with read access to the vector store can reconstruct sensitive content even though the chat UI never displayed it. This is the pattern most "AI for nonprofits" tools ship by default.
7. Audit trail requirements
A PII redaction system is only defensible if its behavior is verifiable after the fact. A complete audit record per AI interaction should include:
- Timestamp, actor (user ID), and source document IDs retrieved
- Span-level detection output: offsets, entity types, the layer that produced each detection, confidence
- Redaction policy applied (tokenize / pseudonymize / generalize / suppress) per span
- Hash of the pre-redaction input and the post-redaction payload sent to any LLM
- Model identifier, version, and whether the call hit a no-retention endpoint
- The final output returned to the user, with citation back to source records
These records should be queryable by the nonprofit, not just by the vendor, and exportable for board review or incident response.
8. Generic PII tools vs nonprofit-tuned redaction
The PII redaction market is built for developers and enterprises. Those tools are good at what they were designed for and blind to what nonprofit data actually contains.
| Capability | Generic PII tools | Nonprofit-tuned redaction |
|---|---|---|
| Direct + financial identifiers | Strong | Strong |
| Health / immigration / hardship in free text | Largely missed | Detected (domain-tuned, Layer 3) |
| Quasi-identifier generalization | Manual config | Built into policy |
| Default enforcement point | Often query-time | Write-time |
| Referential integrity across donor records | Not a goal | Tokenization vault |
| Audit trail for board / incident response | Developer logs | Exportable, nonprofit-queryable |
The gap is not detection horsepower. It is that a generic tool does not know that "asked us to pause solicitations during treatment" is a health disclosure, and does not run early enough in the pipeline to keep it out of the vector store.
9. Vendor evaluation checklist (scored)
Eight questions to ask any AI vendor before connecting it to a donor database:
- Does PII detection run at write-time, query-time, or both?
- Which detection layers are in production: regex only, NER, domain-tuned, guardrail?
- Are nonprofit-specific PII categories (health, immigration, family hardship) covered?
- What is stored in the vector store: raw text, redacted text, or both?
- Which redaction strategy is applied per PII category, and is it configurable?
- What no-retention guarantees exist on third-party LLM calls, and where are they contractual?
- Can the audit log be exported and queried by our team without vendor mediation?
- Is there a documented procedure for re-identification incident response?
Score it. Give one point for each question you can answer with the secure option (write-time detection, all four layers in production, nonprofit categories covered, redacted vector store, configurable per-category strategy, contractual no-retention, an exportable audit log, and a documented incident-response procedure).
- 6 to 8: defensible. Reasonable to connect to a donor database.
- 3 to 5: material gaps. Pilot with redacted or non-sensitive data only until the gaps close.
- 0 to 2: do not connect this tool to a donor database.
10. Reference implementation
How Gratefully handles this
- Four-layer detection pipeline (regex → NER → nonprofit-tuned classifier → LLM guardrail) runs at write-time, before data is embedded or indexed.
- Tokenization preserves referential integrity across donor records; pseudonymization is used for LLM prompt payloads to reduce vendor-side exposure.
- No customer data is used to train any model, enforced by environment isolation, not policy alone.
- Per-interaction audit trail with span-level detection records, exportable by your team.
- A board-ready Safe AI Policy Pack documenting all of the above.
Related reading: AI Data Security for Nonprofits · Gratefully vs ChatGPT
11. Frequently asked questions
12. Sources and references
- BBB Wise Giving Alliance — Charity AI Collaboration
- BBB Give.org Donor Trust Report — data privacy poll
- CyberSecurity Nonprofit (CSNP)
- Morris, Kuleshov, Shmatikov, Rush — Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023
- OpenAI — How your data is used to improve model performance
- OpenAI — Enterprise privacy
- NIST SP 800-122 — Guide to Protecting the Confidentiality of PII
- The Nonprofit Alliance — Top Ten AI Usage Policy Considerations for Nonprofits
About the author
Muddsar Jamil
Founder, Gratefully
Muddsar Jamil is the Founder of Gratefully, the AI donor relationship platform built so nonprofit teams can use AI on donor data without exposing PII to third-party models. He works directly with nonprofit operations and development leaders on safe AI adoption — the architecture in this paper is the approach Gratefully ships.
Connect on LinkedInAbout Gratefully
Gratefully is the AI donor relationship platform for nonprofit teams. It is built so that donor PII is redacted at write-time before any data is embedded, indexed, or sent to a language model. Learn more at gratefully.io.
Gratefully · Whitepaper v2.0 · Published May 18, 2026 · Updated June 29, 2026. This document addresses concerns raised in public guidance from give.org and csnp.org regarding generative AI use with donor data.