Start with the records, not the model
Most nonprofit AI conversations open with a tool and end with a pilot nobody uses. The better opening question is which records already exist, who owns them, and whether the identifiers line up. In an operating nonprofit the answer is usually four systems with four owners: a case management or program database run by service staff, a donor CRM run by development, a fund accounting ledger run by finance, and a pile of PDFs and spreadsheets that carry the reporting requirements nobody automated. On the funder side it is a grants management system, an investment or treasury record, and the board packet.
Those four systems rarely share a key. The case system assigns a client ID; the donor CRM assigns a constituent ID; the ledger tracks a program code and a grant code; the PDFs use whatever the program officer typed. Nothing joins cleanly, which is why the annual report takes six weeks and why the number in the board deck does not match the number in the federal financial report. The engineering problem is identity and lineage before it is anything else.
There is also a large public record that most organizations never touch. Electronic filing of Form 990 has been mandatory since the Taxpayer First Act of 2019, and the IRS publishes the e-filed returns as machine-readable XML. Several hundred thousand full Form 990 and 990-EZ returns land there each year, alongside roughly 1.8 million entries in the IRS Business Master File. Schedule I lists every domestic grant above $5,000 a filer made. Single audit packages are public at the Federal Audit Clearinghouse, which moved from the Census Bureau to GSA on October 1, 2023. Federal assistance awards, with their Assistance Listing numbers and Federal Award Identification Numbers, sit on USAspending.gov. Peer benchmarking, funder prospecting, and subrecipient risk screening all draw on data you can download today without asking anyone's permission.
Where the records live and what each one is good for
Before scoping anything, write down the four or five systems by product name, the row counts, the owner, and the export path. That single page decides more about feasibility than any model comparison.
| Record system | What it holds | What it can support |
|---|---|---|
| Case management Apricot, CaseWorthy, ETO, Salesforce | Enrollments, services delivered, assessments, case notes, exit reasons | Outcome measurement, caseload forecasting, note summarization for handoffs |
| Donor CRM Raiser's Edge NXT, Bloomerang, Neon, DonorPerfect | Gifts, pledges, appeals, event attendance, soft credits | Lapse prediction, segmentation, duplicate resolution, appeal-level attribution |
| Fund accounting Financial Edge NXT, Sage Intacct, QuickBooks | Grant codes, restrictions, functional expense allocation, payroll distribution | Burn-rate forecasting by award, indirect recovery checks, audit preparation |
| Grants management Fluxx, Foundant, SmartSimple, Submittable | Applications, budgets, reports, payment schedules, review scores | Intake extraction, eligibility triage, portfolio search, report drafting |
| Public filings IRS 990 XML, FAC, USAspending | Peer financials, grant histories, audit findings, federal award records | Prospect research, benchmarking, subrecipient risk screening |
| Mandated systems HMIS, state reporting portals | Standardized program data on a fiscal-year data-standard cycle | Required reporting, cross-agency measurement where consent allows |
Readiness by workflow: how often the data supports a build without new collection
Editorial weighting from public sources and practitioner reading — illustrative, not a measured statistic.
What the funding rules require you to be able to prove
Federal awards to nonprofits run under 2 CFR Part 200, the Uniform Guidance, which OMB revised in April 2024 with an effective date of October 1, 2024. Several thresholds moved and they change build decisions. The single audit trigger rose from $750,000 to $1,000,000 in federal awards expended in a fiscal year under 2 CFR 200.501. The de minimis indirect cost rate rose from 10 percent to 15 percent of modified total direct costs under 2 CFR 200.414(f). The equipment capitalization threshold rose from $5,000 to $10,000 in the 2 CFR 200.1 definitions.
The provisions that shape a data system are the plainer ones. Section 200.302 requires financial management records that identify each award by title, Assistance Listing number, and Federal Award Identification Number. Section 200.303 requires internal controls sufficient for someone else to check the work. Section 200.430(i) requires personnel charges to be supported by records that reflect the work actually performed, which is the reason time allocation across awards is a data problem before it is an HR problem. Section 200.332 makes a pass-through entity assess subrecipient risk and monitor accordingly. Section 200.334 sets a three-year retention period, and 200.344 gives you 120 calendar days after the period of performance to file final reports. Subawards of $30,000 or more carry reporting obligations under the Federal Funding Accountability and Transparency Act.
Read those together and one design rule falls out: every number a system produces has to be traceable back to the source rows that made it, with the transformation visible. A dashboard that cannot answer "which transactions are in this figure" is worse than no dashboard, because it will be cited in a report and then contradicted by the ledger.
The uses that pay for themselves
The honest list is shorter than the vendor list, and every item on it has a measurable before-and-after.
- Application intake extraction. Pull budget lines, service area, population served, and requested amount out of narrative PDFs into structured fields a reviewer can correct. Measured in reviewer minutes per application.
- Eligibility triage. Check the mechanical gates: registration status, geography, award ceiling, required attachments. A person still makes every decline.
- Report drafting from structured data. Assemble the narrative sections of a recurring performance report from the ledger and the case system, with each figure linked to its source query.
- Entity resolution. Collapse duplicate constituent and household records across the CRM and the case system so counts stop disagreeing.
- Subrecipient risk screening. Combine Single Audit findings, 990 signals, and payment history into a ranked monitoring list that satisfies 2 CFR 200.332 documentation.
- Portfolio search. Retrieval over a funder's own grant history so a program officer can find the four prior grants that touched this problem in ninety seconds.
- Case note summarization. Shift handoff summaries drawn from the notes, held inside the organization's own boundary, with the source notes always one click away.
- Lapse and renewal modeling. Plain gradient-boosted models on gift history beat anything exotic here, and they are auditable by a development director.
Notice what is missing. Nothing on that list makes a funding decision, denies a service, or scores an applicant's worth. That boundary is not squeamishness. A model that ranks applicants creates a record the organization will be asked to defend, and defending a ranking is far harder than defending a checklist a person applied.
The confidentiality rules pick the architecture
In this sector the compliance layer decides the deployment shape before anyone benchmarks a model. Four rules do most of the work.
Substance use records. 42 CFR Part 2 governs records from federally assisted substance use disorder programs. The 2024 final rule aligned Part 2 more closely with HIPAA and carries a compliance date of February 16, 2026. Part 2 data cannot simply be pooled with the rest of the case record, which forces column-level segmentation and separate consent tracking.
Victim services. The Violence Against Women Act confidentiality provisions at 34 U.S.C. § 12291(b)(2) bar grantees from disclosing personally identifying information about victims. In practice, victim service providers do not enter client identifiers into a shared Homeless Management Information System and keep a comparable database instead. Any measurement design that assumes one shared client table across a coalition is already illegal for part of the coalition.
Education records. If a youth program receives student-level data from a district, FERPA at 34 CFR Part 99 governs it, usually through the school official exception at 34 CFR 99.31(a)(1), which requires the district to keep direct control over the use. That control requirement is why a vendor-hosted model endpoint is often the wrong answer and a processor inside the district's own agreement is the right one.
Health and payment data. HIPAA at 45 CFR Parts 160 and 164 reaches a nonprofit only if it is a covered entity or a business associate, which many are and many are not. Payment card data brings PCI DSS v4.0.1, whose future-dated requirements became mandatory on March 31, 2025.
Two more constraints catch people by surprise. Donor identities on Schedule B are not public, and Americans for Prosperity Foundation v. Bonta, 594 U.S. 595 (2021), struck California's blanket collection of them, so treat donor lists as a protected class of data rather than ordinary CRM content. And while California's consumer privacy statute reaches only for-profit businesses, the Colorado, Delaware, and Oregon privacy laws do reach nonprofits, so a national organization cannot assume it is outside consumer privacy law. Accessibility applies too: HHS's 2024 rule under Section 504 of the Rehabilitation Act sets WCAG 2.1 Level AA for the web content of entities that receive HHS funding, phased in by employer size, which means an applicant portal has an accessibility requirement attached to it.
The practical effect is a fork. If the workflow touches Part 2, VAWA, or FERPA data, the model runs inside your boundary, on a processor bound by your agreement, with logging you own. An 8B-class open-weight model on a single 24 GB card handles summarization, extraction, and redaction well enough for those workflows. If the workflow touches only public filings, ledger data, or de-identified aggregates, a commercial API with a signed data processing agreement is fine and cheaper.
Data quality decides the result, not model choice
Across this sector the binding constraint is almost never the model. It is that the outcome field was optional, so it was filled in when a case manager had time. It is that the program was renamed in 2023 and the old name still appears in a third of the rows. It is that dates were stored as free text, that exit reasons drifted as staff turned over, that the CRM has three records for the same household, and that consent flags were never captured in a queryable field at all.
Swapping a frontier model for a better frontier model moves accuracy by a few points. Fixing a 30 percent null rate on the outcome field moves the answer from unusable to usable. So the first deliverable in any engagement we take in this sector is a data quality report: field-level completeness by year, duplicate rate under a defined matching rule, referential integrity between the case system and the ledger, and a list of every field the organization believes is required that turns out not to be enforced. That report costs a small fraction of the build and it regularly changes what gets built.
It also protects the measurement claim. Outcome evidence has tiers, and the four tiers in ESEA § 8101(21)(A), which are strong, moderate, promising, and demonstrates a rationale, are the vocabulary funders increasingly use. The Foundations for Evidence-Based Policymaking Act of 2018 pushed federal agencies toward learning agendas and evaluation plans, which pushes the same expectations downstream to grantees. You cannot reach a higher evidence tier on records with unenforced fields, and no model repairs that.
Volumes, latency, and cost in real numbers
This sector's data is small by engineering standards, and that is good news for cost. A human services agency serving 8,000 people a year holds roughly 8,000 client rows, 150,000 to 400,000 service transactions a year, and 30 to 80 GB once scanned documents are included. A community foundation reviewing 3,000 applications to make 1,200 grants holds perhaps 75,000 to 120,000 pages of application narrative per cycle. Ten years of donor history for a mid-size organization is a few million rows. All of that fits comfortably in a single managed Postgres instance with object storage behind it, in the low hundreds of dollars a month, with no distributed system anywhere in the design.
Inference cost follows the same shape. A 30-page application narrative is roughly 20,000 to 30,000 input tokens. At prevailing per-million-token prices for frontier models, extracting structured fields from a full 3,000-application cycle costs in the hundreds of dollars, not the tens of thousands. Embedding half a million text chunks for retrieval is a one-time cost measured in single dollars. The expensive line item in this work is engineering time and staff review time, which is exactly why the pilot should be scoped around reviewer minutes saved rather than tokens consumed.
Latency targets split three ways. A staff-facing lookup or portfolio search should return in under two seconds or people stop using it. Document extraction can take 30 to 90 seconds per application because it is queued and nobody is watching. Overnight batch work, such as re-scoring a donor file or refreshing a risk list, has an eight-hour window and runs fine on one worker. Nothing in this sector needs real-time streaming, and any proposal that includes it is selling you infrastructure you will pay to maintain and never use.
The grantmaker side
Funders have a different set of pressures and better-structured data. A private non-operating foundation must meet the minimum distribution requirement of IRC § 4942, generally 5 percent of the fair market value of non-charitable-use assets, and pays the net investment income excise tax at the flat 1.39 percent rate under IRC § 4940. Grants to entities that are not U.S. public charities require expenditure responsibility under IRC § 4945 or an equivalency determination, for which Rev. Proc. 2017-53 supplies the good-faith framework. Each of those is a documentation workflow with deadlines, which is to say a data problem.
The highest-value engineering work on the funder side is usually the least glamorous. Give reviewers structured fields extracted from narrative applications so they read for judgment rather than for facts. Build retrieval over the foundation's own grant history so institutional memory survives staff turnover. Reconcile payment schedules against the ledger so payout tracking is continuous rather than a March scramble. Pull peer grant histories from public 990 Schedule I data so program staff can see who else funds a field. Every one of those has a measurable time saving and none of them puts a model between an applicant and a decision.
How to scope a first engagement that can fail cheaply
The failure mode we see in this sector is a large multi-year platform contract signed before anyone confirmed the data supports it. The alternative is a short fixed-price engagement with a written kill criterion agreed in advance.
A first engagement that can fail for a small number
Three contract terms make the cheap failure real. Fixed price, so the downside is bounded and known before the board approves it. A kill criterion in writing, so stopping is a planned outcome rather than an argument. And full handover of code, schemas, prompts, evaluation sets, and documentation at the end, whichever way the decision goes, so nothing you paid for stays with the vendor. If the engagement stops, the data quality report alone usually pays for the whole thing, because it tells you what to fix before anyone builds anything.
One more term worth negotiating up front: whether the model spend is an allowable direct cost on a specific award. Under 2 CFR 200.413 a cost charged direct must be identifiable to that award. Metered inference billed at the workflow level can be, if the logging separates it by award. Billed as one flat subscription across the organization, it is an indirect cost recovered through the 15 percent de minimis rate. That decision is easier to make in week zero than in the audit.
Bottom line
Nonprofits and funders already hold enough data to make several workflows meaningfully faster and cheaper, and the public record adds a substantial second layer for free. The work that produces value is unglamorous: fix the identifiers, prove the lineage, respect the confidentiality classes that federal law already set, and keep every decision with a human. Our engineers build these systems the same way we build for federal customers, with the audit trail designed in from the first commit rather than added when someone asks for it.
Frequently asked questions
Usually yes for extraction, search, and reporting workflows, and often no for outcome attribution. The way to find out is a two-week data quality report covering field completeness by year, duplicate rate, and referential integrity between the case system and the ledger. That report costs far less than a build and frequently changes what gets built.
It depends on the confidentiality class of the field, not on the organization. Records covered by 42 CFR Part 2, VAWA confidentiality at 34 U.S.C. § 12291(b)(2), or FERPA generally belong inside your own boundary on a processor bound by your agreement. Public filings, ledger data, and de-identified aggregates are usually fine with a commercial provider under a signed data processing agreement.
Effective October 1, 2024, the single audit threshold rose to $1,000,000 in federal awards expended, the de minimis indirect rate rose to 15 percent of modified total direct costs, and the equipment capitalization threshold rose to $10,000. The record-keeping obligations in 2 CFR 200.302, 200.303, and 200.430(i) are unchanged and still drive most system design.
We advise against it. Mechanical eligibility checks are fine and easy to defend. A merit ranking creates a record the organization will have to explain to a declined applicant, a board, or an auditor, and explaining a ranking is much harder than explaining a checklist a person applied.
Six weeks, fixed price, one workflow, with a written stop criterion agreed before work starts and full handover of code and documentation whichever way the decision goes. Infrastructure for this sector typically runs in the low hundreds of dollars a month, and inference for a full application cycle usually lands in the hundreds of dollars.