Abstract
Public guidance from sector bodies including give.org and 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. 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 the industry 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 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).
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. 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 are demonstrably invertible under attack. 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 |
3. 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, because LLM-only PII detection is non-deterministic and has documented false-negative rates above 8% on long-form text.
4. Redaction strategies
Detection identifies what is PII. Redaction decides what to do with it. The right strategy depends on the downstream task.
Tokenization
Replace PII with reversible tokens (e.g. <PERSON_07A3>) backed by a vault. Preserves referential integrity across documents — the same donor stays the same token. Required when downstream analytics depend on cross-document linking.
Pseudonymization
Replace with plausible but synthetic values (e.g. Margaret → Susan). Useful for LLM prompts where the model needs realistic-looking text to generate coherent output.
Generalization
Replace specific values with bucketed ranges (gift of $14,500 → "$10K–$25K range"). Reduces re-identification risk on quasi-identifiers.
Suppression
Remove the span entirely, replace with [REDACTED]. Highest privacy, lowest utility. Use when the field is irrelevant to the downstream task.
5. 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). 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; 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.
6. 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, 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.
7. Vendor evaluation checklist
- 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?
How Gratefully implements this
Reference implementation
- 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.
- Board-ready Safe AI Policy Pack documenting all of the above.
Related reading: AI Data Security for Nonprofits · Gratefully vs ChatGPT
Gratefully · Whitepaper v1.0 · Published May 18, 2026. This document addresses concerns raised in public guidance from give.org and csnp.org regarding generative AI use with donor data. Citations available on request.