Superintelligence Readiness for Nonprofits: Clean Donor Records First

For most nonprofits, the first useful AI agent is a staff assistant, not a public chatbot. It can draft acknowledgement letters, summarize grant reporting requirements and answer internal questions about volunteer schedules, but it can do this safely only when donor, volunteer and grant records are clean, classified and reachable through narrow permissions. Clean the records first, decide what the agent may read and change, and connect it last.

Key takeaways

• Start from the records an agent would actually touch, not from the model you would like to try.
• Sort supporter, volunteer and grant data into sensitivity tiers before any connection is made.
• Give the agent a minimal view of records, and let it write only through actions a staff member has approved.
• Assign a named reviewer to every output that reaches a donor, a volunteer or a funder.
• Schedule a permission review and a written stop procedure from the first week, not after the first incident.

Why supporter records come before the agent

Most nonprofit data was never designed to be read by software. Donor histories sit in one relationship tool, volunteer hours sit in a spreadsheet maintained by a single coordinator, and grant conditions live in a PDF that the finance lead remembers. Each source may be accurate on its own, yet they often disagree about names, household links, consent status and deadlines. An agent that reads them will give confident answers based on whichever record it reaches first, and a staff member may not notice the mismatch until a letter has already gone out.

The privacy stakes are also higher than in many businesses. A supporter file can reveal giving capacity, health or family circumstances written into a note, religious or political affiliations implied by a donation pattern, and the fact that someone volunteers with a vulnerable group. Data protection rules such as the LGPD in Brazil treat much of this as personal data that needs a lawful basis and a clear purpose. Before an agent touches any of it, a staff member should be able to say what each field is for and who is allowed to see it.

There is also a quieter risk. Free-text fields, imported emails and scanned forms can contain instructions written for a person, not for software. A volunteer application might include a sentence that tries to change how an assistant summarizes it. Treat anything inside a record as content to be read, never as a command to be followed, and design the agent so that its permissions do not depend on what a note says.

Map the three record families before connecting anything

Write a short inventory for each family: donors and supporters, volunteers, and grants. For each one, list the system where the record lives, the person who owns it, the fields that identify someone, the fields that describe a relationship, and the fields that carry sensitive meaning. Give special attention to notes fields, because free text is where people write things they would never put in a structured column.

Grant records have a different shape. They hold spending restrictions, reporting dates, funder contacts and budget lines that must match invoices. An agent that drafts a progress report needs the reporting calendar and the approved narrative sections, not the full budget ledger. Keeping those two needs apart is one of the simplest decisions in the whole project, and it is easy to skip when the ledger is the only place the data appears to be complete.

The inventory is also where you find the questions nobody has answered. Who approves a change to a consent flag? Which volunteers were removed from a program but still appear in a shift list? Which donors asked not to be contacted by email, and does every system know that? Write these questions down as open items. An agent cannot resolve them, and it will quietly inherit whatever answer the data currently implies.

A four-week cleanup plan before any agent is connected

The sequence below is deliberately plain. It assumes a small team with one operations lead and a part-time person who can export data.

• Week one: export a sample from each system and list the duplicates, blank owner fields and conflicting consent flags you find.
• Week two: name an owner for every field that will be exposed, and retire fields that nobody uses or can explain.
• Week three: build a minimized view for the agent with stable record identifiers, consent status and only the fields its first task requires.
• Week four: test that view with real but low-stakes questions, such as which grants report next quarter or which volunteer roles still need a background check, and log every wrong or overexposed answer.

At the end of the fourth week, two things must be true. Every field the agent can read has a named owner, and every action it can take has a written approval rule. If either is missing, the agent stays in test mode. This is a slower path than many nonprofits expect, but it is the one that survives the first audit question from a board member or a funder.

Decide what the agent may see, change and never touch

Use a written decision sheet with four tiers. Keep it short enough that a board member can read it in ten minutes.

• Readable without approval: program facts, public campaign calendars, grant reporting deadlines and approved thank-you templates.
• Readable only on a staff request: named donor history, volunteer contact details, notes about hardship or health, and grant budget lines.
• Changeable only after approval: drafts of letters, suggested tags on a record and proposed reminders. The agent proposes, and a person confirms.
• Never accessible: bank details, identity documents, and any record where consent has been withdrawn for the purpose in question.

Illustrative scenario: a regional food bank with a small staff wants an agent to help its volunteer coordinator fill Saturday shifts. The first version reads a minimized view with volunteer first names, availability and recent shift history, and it drafts reminder messages that the coordinator sends. It cannot see health notes, cannot send anything on its own and cannot change availability without confirmation. When a volunteer writes in a free-text field that they can no longer lift boxes, the agent flags the note to the coordinator and leaves it out of the shift plan. The coordinator decides what happens next, and the flag itself is logged for the next permission review.

The pattern in this scenario, a narrow read view, proposal-only writes and a logged escalation path, is the same one a larger organization would use for its major donor team. Only the size of the tables changes.

How a managed approach keeps these boundaries in place

Be Human designs and operates this layer as a managed service. The agent's role, memory, tools, permissions and approval boundaries are written down before it runs, and monitoring, recurring evaluations and permission reviews continue after launch. In a nonprofit engagement, the team maps the record families with the organization's owners, builds the minimized view, and tests the agent against the questions staff actually ask. Changes to what the agent can read go through a documented request, so the boundary a board approved stays the boundary in force until someone deliberately changes it. The approach is the same whether the organization is large or has a two-person operations team, but the scope of the first role is always kept small.

For the review cadence and evidence, see how to run a permission review for your AI agents. For a view of how the data, model and tools fit together, see the one-page architecture map for leaders.

Where to start this quarter

Choose one record family, preferably the one where staff already lose the most time copying information between systems, and run the four-week cleanup on that family alone. Leave grant reporting for a second round, because its deadlines and restrictions need more review before an agent relies on them. Name one owner for the agent's permissions and schedule the first review before launch rather than after. Then write a one-page charter that states the role, the records the agent may read and the actions it may only propose. Organizations that want a sequence for this can also read how to choose the first users for an AI agent pilot before they invite anyone into the test.

Take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent safely read our donor database? It can, but only if you give it a restricted view rather than full access to the database. Build a minimized view with stable identifiers, consent status and the fields a specific task requires. Keep sensitive notes out of that view unless a staff member requests them for a stated purpose.

Do we need perfectly clean data before we start? You do not need perfect data, but you do need known data for the records the agent will use. Find the duplicates, missing owners and conflicting consent flags in those fields first and resolve them before connecting anything. The rest of the database can wait until the agent's scope grows.

What should the agent be allowed to change? Start with proposals only, such as drafts, suggested tags and reminders that a staff member confirms before anything is sent or saved. Direct writes to gift records, consent flags or grant budgets should stay outside the first version. Any later change should pass a documented approval step with a named owner.

How do we know the agent keeps working properly and safely after launch? Define a small set of test questions before launch, run them on a fixed schedule, and log every answer a reviewer marks as wrong or overexposed. Review permissions on a calendar, not only after an incident, and keep a written procedure for pausing the agent if a privacy problem appears.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.