Governance structure
AI governance in advancement requires named roles, defined decision authority, and a review cadence. A written policy without an accountable body behind it does not reduce risk.
Accountability model
Governance models that scale use a three-lines-of-defense accountability structure. Adapted for an advancement office:
| Line | Who | Function |
|---|---|---|
| First | Staff who use AI tools and the teams that manage them (prospect research, advancement services, gift officers) | Own the use case. Apply the acceptable use policy. Report concerns. Conduct first-level review of AI outputs before action. |
| Second | AI governance committee, data governance lead, compliance/legal | Set policy. Approve elevated and high-risk use cases. Conduct vendor assessments. Review incidents and audit findings. |
| Third | Institutional IT audit, internal audit, or external review | Independent verification that governance controls operate as documented. Annual or periodic assurance. |
Committee composition
The governance committee operates as the second line of defense. It does not need to be large, but it needs the right functional coverage.
| Role | Responsibility |
|---|---|
| AVP/VP Advancement (or designee) | Final approval authority for elevated and high-risk use cases. Accountable for framework compliance. |
| Director, Advancement Services or Technology | Operational oversight of AI tools. Vendor relationship management. Maintains the system inventory. |
| Data governance lead | Data classification. Access control review. Training data quality assessment. |
| Prospect research director | Oversight of AI in prospect identification, scoring, and segmentation. Output validation. |
| Gift officer representative | Frontline perspective on AI tool usability and donor-facing implications. |
| IT security liaison | Institutional policy conformance. Security review of new tools and data flows. |
| Legal/compliance (ad hoc) | Regulatory review for elevated and high-risk use cases. Not a permanent seat unless institutional policy requires it. |
Decision authority by risk tier
| Tier | Examples | Approval required |
|---|---|---|
| 1. Routine | Grammar and style tools, meeting transcription, internal summarization, email drafting with human review | Manager approval + acceptable use acknowledgment |
| 2. Elevated | Prospect scoring, donor segmentation, content generation for external distribution, wealth screening AI | Committee review + data governance assessment |
| 3. High | Predictive gift capacity models, automated donor communications, AI-driven solicitation timing, agentic AI systems, any use case that touches FERPA or HIPAA data | Committee approval + legal review + annual audit |
Review cadence
| Interval | Activities |
|---|---|
| Quarterly | Review AI system inventory for accuracy. Review incident log. Approve pending Tier 2 requests. Review CRM vendor release notes for new AI features. |
| Annually | Full framework review and policy update. Vendor contract review. Bias and fairness audit for Tier 2 and 3 use cases. Training compliance verification. Regulatory update. |
| Event-driven | Tier 3 approvals. Incident response. New vendor evaluation. Regulatory change (new state privacy law, FERPA guidance, institutional policy update). |
AI system inventory
Maintain a registry of every AI tool and AI-powered feature in use across the advancement operation. Most offices run more AI than they realize. CRM platforms have been shipping AI features for years, and platform updates add new capabilities without separate procurement review.
Registry fields
For each AI use case, document:
| Field | Description |
|---|---|
| System name | Tool or feature name (e.g., "CRM prospect scoring," "wealth screening service") |
| Vendor or source | Platform vendor, open-source project, or internal build |
| Function | What the AI does, in plain language |
| Business process | Which advancement workflow consumes its output |
| Data inputs | What data the AI ingests (giving history, biographical, wealth, engagement, student records, clinical encounter data) |
| Data outputs | What the AI produces (scores, segments, text, recommendations, automated actions) |
| Data residency | Where data is processed and stored (on-premises, vendor cloud, region) |
| Training data scope | Is the model trained on your data only, aggregated multi-client data, or a pre-trained foundation model? |
| Decision impact | What decisions does the output influence? (informational, advisory, determinative) |
| Human review | Is every output reviewed by a person before action is taken? |
| Constituent exposure | Can the AI's output affect a constituent's experience? (e.g., which solicitation they receive, whether they appear on a contact list) |
| Regulatory surface | Does this use case touch FERPA, HIPAA, or state privacy law data? |
| Risk tier | 1, 2, or 3 per the classification matrix |
| Owner | Named person responsible for this use case |
| Last reviewed | Date of most recent governance review |
Advancement AI use case reference
Audit your current systems against this list. For each category, identify which tools your office runs and whether they have been classified and documented.
Prospect research and scoring
- Wealth screening AI (any vendor or data provider)
- Propensity, affinity, and capacity scoring (CRM-native or third-party)
- Prospect identification and discovery models
- Planned giving likelihood models
- Major gift readiness scoring
- Alumni engagement scoring
Donor communications
- AI-generated fundraising copy (appeals, proposals, stewardship reports)
- Email subject line optimization
- Send-time optimization
- Personalization and dynamic content engines
- Chatbots and virtual assistants on giving pages
Analytics and decision support
- Predictive gift amount models
- Donor retention and lapse prediction
- Campaign response modeling
- Portfolio optimization and assignment
- Event attendance prediction
Agentic AI
- Platform-native AI agents (fundraising, service, engagement)
- Custom AI agents that query CRM data and take actions
- Automated outreach sequencing driven by AI triggers
Operations
- Meeting transcription and summarization
- Gift entry classification and coding
- Duplicate record detection and resolution
- Data enrichment and append services
- Document processing (OCR on pledge forms, bequest documents)
Risk classification
Four factors determine an AI use case's risk tier: data sensitivity, decision impact, constituent exposure, and regulatory surface area. Classification drives the governance rigor applied to each use case.
Factor 1: Data sensitivity
| Level | Description | Advancement examples |
|---|---|---|
| Public | Available from public sources | Published giving recognitions, public board membership, SEC filings, real estate records |
| Internal | Institutional data not publicly available | Giving history, event attendance, engagement scores, solicitor assignments, contact reports |
| Sensitive | Subject to regulatory protection or reasonable donor expectation of privacy | Student records (FERPA), patient data (HIPAA), anonymous gift flags, bequest intentions, wealth screening results, family and relationship data |
| Restricted | Specific legal restrictions on processing | Social Security numbers, financial account numbers, protected health information, legal case details |
Factor 2: Decision impact
| Level | Description | Advancement examples |
|---|---|---|
| Informational | Output informs human judgment but does not drive action | Research summaries, meeting notes, background briefings |
| Advisory | Output recommends actions that a person reviews before executing | Prospect ratings, suggested ask amounts, content drafts for review, portfolio recommendations |
| Determinative | Output triggers or shapes action without case-by-case human review | Automated email sends, portfolio assignments by algorithm, solicitation sequencing, agentic actions |
Factor 3: Constituent exposure
Constituent exposure measures whether an AI system's output can change a constituent's experience with your institution. Scoring models that determine who receives a solicitation carry higher constituent exposure than internal research tools that inform a conversation between colleagues.
Factor 4: Regulatory surface area
Use cases that process FERPA-protected student records, HIPAA data in grateful patient programs, or constituent data subject to state AI and privacy laws carry additional compliance obligations that increase the risk tier regardless of other factors. See the compliance section for the full compliance map.
Risk tier matrix
Assign the tier using the highest applicable factor. A use case with internal data but determinative impact is Tier 2, not Tier 1. A use case with any regulatory exposure is at minimum Tier 2.
| Informational | Advisory | Determinative | |
|---|---|---|---|
| Public | Tier 1 | Tier 1 | Tier 2 |
| Internal | Tier 1 | Tier 2 | Tier 2 |
| Sensitive | Tier 2 | Tier 2 | Tier 3 |
| Restricted | Tier 3 | Tier 3 | Tier 3 |
Regulatory override: Any use case that processes FERPA education records, HIPAA-protected health information, or data subject to state AI governance law is at minimum Tier 2, regardless of where it falls on the matrix. Any use case involving automated consequential decisions about constituents under applicable state law is Tier 3.
Assessment procedure
For each use case in the inventory, complete this assessment:
- Classify the data inputs by sensitivity level. Use the highest-sensitivity element, not the average.
- Classify the decision impact. If the output can reach a constituent without per-instance human review, the impact is determinative.
- Evaluate constituent exposure. Can a constituent's experience change because of this AI's output?
- Check for regulatory exposure. Does the use case touch FERPA, HIPAA, state privacy, or EU AI Act data?
- Assign the risk tier using the matrix. Apply the regulatory override if applicable.
- Record the classification in the system inventory with the rationale.
Data governance
Data governance for AI extends beyond access control. It covers what data enters AI systems, how that data trains or conditions models, and what controls prevent institutional data from leaking into general-purpose models.
Data classification for advancement
Document which data elements in your advancement systems fall into each sensitivity level. These categories are a starting reference; adapt them to your institution's data inventory.
Internal
- Lifetime giving totals and gift detail (dates, amounts, designations, payment types)
- Event attendance and participation history
- Email engagement metrics (opens, clicks, unsubscribes)
- Solicitor and volunteer assignments
- Contact reports (non-confidential)
- Engagement and participation scores
- Communication preferences
Sensitive
- Student enrollment status, academic records, financial aid data (FERPA)
- Patient status and clinical encounter data (HIPAA)
- Bequest and planned gift intentions
- Anonymous and confidential gift flags
- Family and relationship data
- Wealth screening results and estimated net worth
- Contact reports marked confidential
- Donor-requested communication restrictions
- Political giving data (from FEC or state filings)
Restricted
- Social Security numbers
- Financial account and credit card numbers
- Protected health information (diagnosis, treatment, clinical notes)
- Legal case details
Data quality requirements
Before deploying any Tier 2 or Tier 3 AI use case, assess the quality of the input data against these criteria:
- Are the input data fields populated at rates sufficient for the model's intended purpose? Document the population rate for each required field.
- Is there a known collection bias in the data? (e.g., prospect research coverage concentrated in certain geographies or demographics, giving data missing from a predecessor system, wealth screening coverage skewed by vendor data sources)
- Are constituent records deduplicated to a level where model outputs will not be distorted by duplicate records?
- What is the data currency? Document the refresh cadence for external data (wealth screening, demographic appends) and the staleness threshold for each.
- Are data retention policies documented and enforced? Is expired data excluded from AI model inputs?
- For models trained on institutional data: is the training dataset representative of the population the model will score? Document any known gaps.
Training data controls
Separate governance is required for AI systems that train on your institutional data versus systems that use pre-trained models and process your data only at inference time.
- Document whether each AI system in the inventory trains on your data, and if so, whether that training data is used solely for your institution or aggregated with other clients' data.
- Verify whether your CRM platform allows opting out of data use for model training. Major CRM vendors reserve the right to use customer data for global model training unless the organization opts out. Check your platform's admin settings and master service agreement for opt-out mechanisms.
- For AI vendors that train on aggregated client data: confirm that your institution's data cannot be identified or reconstructed from the trained model.
- When staff use standalone generative AI tools: verify that the enterprise license excludes user inputs from model training. Personal-tier accounts may not offer this exclusion.
Access control and data minimization
- AI tools access only the data elements required for their function. Scope access to the minimum necessary fields.
- Staff access to AI outputs follows the same role-based access controls as the underlying data.
- Vendor data access is documented in contracts and limited to the scope of service.
- Audit logs exist for AI system access to sensitive and restricted data.
- Restricted data (SSNs, financial account numbers, PHI) is excluded from AI system inputs unless the system has been specifically approved for that data class under Tier 3 governance.