Blackbaud's Development Agent: The Donor-Data Governance Question

The announcement is straightforward. On May 15, 2026, Blackbaud released its Development Agent to Raiser's Edge NXT customers in the United States, with rollout to international customers and Blackbaud Enterprise Fundraising CRM customers scheduled later in 2026. The product is described as an autonomous system "designed to manage complex donor workflows autonomously, identifying and engaging prospects at a scale impossible for human teams alone." Blackbaud's Responsible AI framing cites the NIST AI Risk Management Framework, OWASP guidance, and the Cloud Security Alliance AI Control Matrix as reference standards, alongside the firm's existing SOC 1, SOC 2, PCI DSS, and HIPAA attestations. That is a credible vendor posture. It is not, however, the governance posture of the nonprofit. The vendor's controls are the floor; the nonprofit's controls are what the audit committee will be asked about. A mid-sized nonprofit with an annual operating budget between ten million and one hundred million dollars, a development team of four to twenty, and a Raiser's Edge instance that has accreted twenty years of donor records is now the operator of an agentic system that touches restricted-gift documentation, prospect research, planned-giving correspondence, and IRS substantiation workflows. The question is not whether to adopt the Development Agent. The question is what to put in place before the toggle is flipped. What the Development Agent actually does, and why the marketing framing understates it The Blackbaud marketing materials describe the Development Agent as a fundraising productivity tool, a system that helps gift officers manage larger portfolios, surfaces engagement opportunities the human team would miss, and orchestrates outreach across email, phone, and direct-mail channels. That description is accurate, and it is also incomplete. An autonomous agent that identifies prospects, drafts outbound communications, schedules engagement actions, and updates donor records is making consequential decisions about who is contacted, with what message, at what cadence, and with what attribution back to the gift record. Each of those decisions is a data-handling event, and each of those events touches a regulated artifact. A mid-sized nonprofit running Raiser's Edge typically holds donor PII (name, address, email, phone, employer, household relationships), gift records (amount, date, designation, restriction language, acknowledgment status), prospect research (wealth screening output, capacity ratings, philanthropic affinity notes, sometimes derogatory information), and a meaningful subset of planned-giving documentation (bequest intentions, charitable remainder trust references, beneficiary designations). On top of that, organizations with program operations frequently link beneficiary records, clients served, scholarships awarded, services rendered, to donor records for impact reporting. The Development Agent does not need access to all of this to operate, but the default scope on a typical Raiser's Edge install will expose more than the nonprofit's leadership realizes. This is the pattern Securem has named elsewhere, the gap between what a vendor-provided agent can technically do and what the operator has explicitly authorized it to do. The agent supervision protocol for regulated operators is the frame to apply here. The Development Agent is not a feature; it is a new actor on the system of record, and it inherits whatever permissions the nonprofit's Raiser's Edge configuration grants it. The default configuration is almost never the right one. The donor-data classification map every nonprofit needs Before the Development Agent is enabled, the nonprofit needs a donor-data classification map. This is not a theoretical exercise. The map is the document the Executive Director hands to the Audit Committee Chair when the question of agentic AI scope is raised, and it is the document the General Counsel references when a state attorney general inquiry arrives. The map should distinguish at least six categories. The first category is donor identity data, names, addresses, email, phone, household linkage, employer. This is the surface that most state donor privacy regimes regulate, and it is the surface most likely to be touched by an autonomous outreach agent. The second category is gift record data, transaction history, designation, restriction language, acknowledgment status. This is the surface that touches IRS substantiation, and any agentic system that drafts or sends acknowledgment-adjacent communications has implications here. The third category is prospect research, wealth screening, capacity ratings, philanthropic affinity, and any narrative notes a development officer has entered. This is the surface most likely to contain inferred or derogatory information that the donor has not consented to, and it is the surface most likely to surface in a state privacy complaint. The fourth category is planned-giving documentation, bequest intentions, charitable remainder trust references, beneficiary correspondence, and stewardship notes tied to fiduciary commitments. This surface is the one that carries the highest reputational and legal risk if mishandled, because planned-giving relationships often span decades and involve family members, attorneys, and trustees outside the donor's immediate household. The fifth category is restricted-gift documentation, the original gift instrument, donor intent language, restriction terms, and the operational record of how restrictions have been honored. The sixth category, where applicable, is beneficiary or program data linked to donor records, the impact-reporting linkage that is increasingly common in mid-sized nonprofits and that frequently introduces a second regulatory surface (FERPA for educational organizations, HIPAA for health-adjacent organizations, state child welfare statutes for human services). For each category, the nonprofit needs to record three things: whether the Development Agent has read access, whether it has write access, and whether the data category is permitted to appear in outbound communications generated or sent by the agent. The default answer for at least three of the six categories should be "no" until a specific, documented business case justifies otherwise. The state donor privacy law landscape and what triggers notice obligations The federal donor privacy regime in the United States is thin. State law is where the obligations live, and the landscape has shifted considerably in the last twenty-four months. California's CCPA and CPRA apply to nonprofits that meet the revenue and data thresholds, and the threshold most often missed is the data threshold, which can be met by a moderately active development operation. Washington State's My Health My Data Act extensions, while primarily oriented to consumer health data, reach into nonprofits operating in health-adjacent program areas. New York's recent AG guidance on charitable solicitation has emphasized donor data handling as an element of the registration and reporting regime. The California Attorney General's charities division has been increasingly active on donor data complaints. The trigger pattern matters. A nonprofit does not generally have a notice obligation when an internal staff member views a donor record. A nonprofit may have a notice obligation when donor data is shared with a vendor that processes it for purposes beyond the immediate transaction, and the analysis becomes more complicated when an agentic system makes inferential decisions about donor segmentation, capacity, or engagement priority based on data combined across sources. The Development Agent is, by design, a system that combines data across sources and makes inferential decisions. The nonprofit's privacy notice, the one on the donation form and in the email footer, needs to be reviewed against what the agent will actually do. This is the same pattern we walked through in the BAA chain procurement field guide. The vendor's data processing addendum is the starting point, not the ending point. The nonprofit needs to map the data flows the agent will create, identify the disclosures that need to be updated, and document the legal basis for each new processing activity. The Audit Committee Chair will ask whether the privacy notice has been refreshed, and the answer needs to be yes, with a dated artifact. IRS substantiation and the agentic engagement complication IRS §170(f)(8) requires a contemporaneous written acknowledgment for any single contribution of two hundred fifty dollars or more, and the acknowledgment must contain specific elements, the amount of cash contributed, a description of any property contributed, and a statement of whether any goods or services were provided in exchange. The IRS guidance on charitable contributions is explicit about the substantiation requirements. The acknowledgment is the donor's documentation for the deduction, and a deficient acknowledgment is a deficient deduction. An autonomous agent that drafts or sends donor communications is, in principle, capable of generating language that could be interpreted as an acknowledgment, even when the operational intent is something different. A thank-you email that references a recent gift amount but does not contain the required "no goods or services were provided" language could be relied upon by a donor and later challenged by the IRS. A pledge follow-up that misstates the designation could trigger a restricted-gift dispute. A planned-giving stewardship message generated without human review could inadvertently create a representation about the organization's intended use of a future bequest. The control here is straightforward in principle and demanding in practice. Any outbound communication from the Development Agent that references a specific gift amount, a specific designation, or a specific tax characterization must pass through a validator gate before it leaves the system. The validator pattern is the architecture to apply, a second model or a deterministic rule set that inspects the outbound message for substantiation-adjacent language and either approves it, blocks it, or routes it to human review. The validator gate is not a nice-to-have; it is the artifact that demonstrates the nonprofit took reasonable care to prevent the agent from generating substantiation-deficient correspondence. Restricted gifts and donor intent, when an AI agent's decisions affect compliance The restricted-gift question is the one most likely to generate a fiduciary problem the board will hear about. When a donor makes a gift with a restriction, for a named scholarship, for a specific program, for a building campaign, the nonprofit is legally and ethically obligated to honor the restriction. The Uniform Prudent Management of Institutional Funds Act, as adopted in most states, governs how restricted funds must be managed, accounted for, and reported. The state attorney general is the enforcement authority for charitable trusts, and donor intent is the framework against which the agent's actions will be judged. An autonomous engagement agent does not directly violate a gift restriction. What it can do is make decisions that complicate the restricted-gift posture in ways that are difficult to detect. Consider a Development Agent that identifies a major donor as a prospect for an unrestricted operating campaign based on engagement signals, and that drafts outreach referencing the donor's prior support for a restricted program. If the outreach implies that the new gift would extend the restricted work but the actual ask is for unrestricted operating funds, the gift documentation that follows may not match the donor's expectation, and the resulting acknowledgment may not match the restriction language. The nonprofit now has a donor-intent dispute risk that did not exist before the agent was enabled. The control pattern is two-part. First, the donor-data classification map should flag restricted-gift documentation as a category that the agent can read for context but cannot directly reference in outbound communications without human review. Second, every gift that arrives in the period following agent-generated outreach should be flagged for restriction-language reconciliation before acknowledgment. This is administrative work the development operation needs to absorb, and it is the kind of operational discipline the AI governance one-page policy is meant to make routine. The three controls the nonprofit needs before enablement Three controls are non-negotiable before the Development Agent is enabled in production. They are not exhaustive, and they are not a substitute for a fuller governance program, but they are the baseline that allows the Executive Director to answer the audit committee question honestly. The first control is per-agent permission scope. The Development Agent should not inherit the full read and write permissions of a development officer. It should have an explicit, documented permission scope that names the data categories it can access, the actions it can take, and the communication channels it can use. The configuration should be reviewed and approved by the Executive Director or designee, and the approval should be a dated artifact in the governance file. This is the same per-agent scoping pattern Securem has applied in property management contexts with Yardi Virtuoso, the principle transfers directly. The second control is the validator gate on outbound donor communications. No message generated by the Development Agent should reach a donor without passing through an inspection layer that checks for substantiation-adjacent language, restriction-adjacent language, and tone or content that violates the organization's communications policy. The validator can be a second model, a rule-based filter, or a human-in-the-loop review queue, and for most mid-sized nonprofits it will be a combination of all three depending on the message type. The validator output should be logged. The third control is the audit log with five required fields. Every action the Development Agent takes should be captured with: the timestamp, the donor record affected, the action performed, the data inputs the agent referenced in making the decision, and the validator outcome if applicable. Five fields, every action, retained for a period no shorter than the organization's general records retention schedule for donor correspondence. This log is the artifact the auditor, the state AG, and the board investigation (if it ever happens) will request. The absence of this log is, by itself, a finding. The agent infrastructure pieces for regulated buyers walks through the log architecture in more detail. The vendor question, what to confirm with Blackbaud before turning it on Blackbaud's stated control posture is strong, but the nonprofit's contract is what binds the relationship. Before enabling the Development Agent, the nonprofit's leadership should confirm five items with Blackbaud in writing. First, the scope of the Business Associate Agreement and the Data Processing Addendum as they apply to the Development Agent specifically, not the platform generally, but the agentic component. Second, whether the nonprofit's donor data is excluded from any model training, fine-tuning, or evaluation activities, and whether that exclusion is contractual or merely operational. Third, the audit-log access the nonprofit will have, whether the logs are exportable, in what format, on what cadence, and how long Blackbaud retains them on the nonprofit's behalf. Fourth, the incident notification commitment, the timeline within which Blackbaud will notify the nonprofit of any security event, model behavior anomaly, or unauthorized data exposure that touches the nonprofit's instance. Fourth-and-a-half, the kill-switch, the mechanism by which the nonprofit can disable the agent immediately if a problem is detected, and the operational state of the system after a disablement. Fifth, the support model, the named contact, the escalation path, and the response-time commitment for agent-specific issues. These are the same procurement questions that apply to any agentic vendor relationship. The trust architecture for regulated AI is the frame, and the trust architecture briefing on frontier model instruction failures underscores why the contractual posture matters even when the vendor's technical posture is strong. The vendor will do what the vendor will do; the contract is what the nonprofit can defend in front of the auditor. What we recommend The Development Agent is a legitimate productivity capability, and a mid-sized nonprofit that builds the governance posture first will benefit from it. A nonprofit that enables it without the governance posture will, at some point, answer a question it does not want to answer. The next sixty days are the window in which the posture should be built. We recommend the following five actions. First, in the next thirty days, commission the donor-data classification map and complete it across all six categories. Assign it to the Director of Development in partnership with the COO or General Counsel, and review it at the next audit committee meeting. The map is the foundation; nothing else works without it. Second, also in the next thirty days, request from Blackbaud the contractual confirmations enumerated above, BAA and DPA scope, training exclusion, audit log access, incident notification, kill-switch, and support model. Get these in writing. If the answers are unsatisfactory, the enablement decision changes. Third, in the next sixty days, design and document the three controls, per-agent permission scope, validator gate, and the five-field audit log. The validator gate is the most operationally demanding piece for a mid-sized development team, and it deserves the most attention. A small nonprofit may choose to start with a human-in-the-loop review queue for all outbound agent-generated messages, and a larger nonprofit may layer a second-model validator on top. Fourth, in the next sixty days, update the donor privacy notice on the website, the donation form, and the email footer to reflect the new data processing activity. Coordinate with the General Counsel and document the dated version history. This is not optional. Fifth, in the next ninety days, establish the board reporting cadence. The audit committee should receive a quarterly report covering: the agent's permission scope as currently configured, the volume of agent-generated communications by category, the validator gate outcomes (approved, blocked, escalated), any incidents or anomalies, and any changes to the vendor relationship. The cadence is the structural answer. Without it, the governance posture decays. Where the Diagnostic fits Securem's Adopt-AI-Safely Diagnostic is designed to compress the work above into a structured engagement, a twenty-one day assessment that produces the classification map, the control specification, the vendor question set, and the board reporting template as defensible artifacts. For mid-sized nonprofits adding the Development Agent to a long-standing Raiser's Edge install, the Diagnostic is the way to enter the next board meeting with the answers already in the file rather than the questions still on the agenda. The Nonprofit & Social Impact vertical is where Securem's nonprofit-specific work lives, and the Development Agent is the first of what will be many agentic systems landing on the donor system of record. The organizations that build the governance posture first will be the ones that benefit from the productivity. The organizations that do not will be the ones answering questions they did not anticipate. For an Executive Director, the implication is direct. The Development Agent is not a fundraising decision. It is a governance decision with a fundraising upside, and the board reporting cadence is the artifact the audit committee will defend.