Operations

Acceptable use policy

Adapt this template for your institution. The acceptable use policy is the staff-facing document. It needs to be clear enough for a gift officer or development coordinator to follow without governance training.

A standalone, print-ready version is available in the templates section.

Monitoring and audit

Monitoring covers testing, metrics, bias evaluation, and performance tracking for active AI use cases. Audit provides the independent verification required by the three-lines-of-defense model.

Ongoing monitoring

Annual audit checklist

• Verify the AI system inventory is complete and current
• Confirm risk tier classifications are accurate. Reclassify any use case where scope, data inputs, or decision impact has changed since last review.
• Review model performance for Tier 2 and 3 use cases against baseline metrics established at deployment
• Assess whether any Tier 1 use case has escalated in practice (e.g., an advisory tool whose outputs are now acted on without per-case review)
• Review vendor AI features added since last audit. Identify any that were activated without committee review.
• Update the acceptable use policy for new tools, use cases, and prohibited practices
• Verify training completion rates against requirements
• Update the compliance map for new regulations, guidance, or institutional policy changes
• Review all documented incidents and their resolutions
• Confirm that vendor contracts and DPAs cover all AI processing in use
• Report findings and recommendations to institutional leadership

Bias and fairness assessment

For Tier 2 and Tier 3 AI use cases that produce scores, segments, or recommendations, conduct a fairness review at least annually.

• Segment model outputs by available demographic dimensions (geography, giving level, degree type, graduation year). Look for patterns where the model consistently over- or under-scores identifiable groups.
• Compare the demographic distribution of AI-recommended prospects against the demographic distribution of your constituent base. Significant divergence warrants investigation.
• If the vendor provides feature importance data, review which input features have the strongest influence on outputs. Flag any feature that serves as a proxy for a protected class attribute.
• Review false positive and false negative rates where measurable (e.g., prospects scored as high-potential who did not give, prospects not surfaced who later gave). Uneven error rates across demographic groups indicate bias.
• Document findings and any corrective actions taken. Record findings in the system inventory entry for the affected use case.

Model performance review

For Tier 2 and 3 use cases that produce measurable predictions:

• Document baseline performance metrics at deployment (accuracy, precision, recall, AUC, or equivalent business metrics such as gift close rate for recommended prospects)
• Compare current performance against baseline at each review cycle
• Identify whether performance has degraded over time (model drift), and if so, whether retraining or replacement is warranted
• Assess whether the model's operating environment has changed since deployment (new data sources, changed constituent demographics, changed solicitation practices) in ways that affect output validity

Incident response

AI incidents require pre-planned response procedures, defined categories, and documented escalation paths.

Incident categories

Response procedure

1. Contain. Stop the affected AI process. For agentic AI, disable the agent immediately. Preserve all logs and evidence, including prompts, outputs, and audit trails.
2. Assess scope. What data was affected? Which constituents were involved? What downstream actions were taken based on AI outputs? Were any external communications sent?
3. Notify internally. Per institutional incident response policy. For data exposure, notify the institutional privacy/security officer immediately. For discriminatory output, notify the governance committee chair.
4. Remediate. Correct any actions taken based on incorrect or biased AI outputs. Contact affected constituents if the incident affected their experience or data. Restore data integrity.
5. Investigate root cause. Was the incident caused by a model error, a data quality problem, a misconfiguration, a vendor issue, or a policy gap?
6. Document. Record the incident in the incident log: date, category, description, scope, root cause, remediation steps, timeline, and assigned owner.
7. Review and improve. Present findings to the governance committee. Update policies, training, controls, or vendor requirements to prevent recurrence.

Training and competency

Staff competency requirements should match role-based risk exposure. Everyone in the advancement office needs AI literacy; staff operating Tier 2 and Tier 3 systems need deeper technical and compliance training.

Requirements by role

Competency areas

Staff using AI tools in advancement should be able to demonstrate understanding of:

• Which tools are approved and what uses each tool is approved for
• What data can and cannot be entered into AI tools, and the difference between enterprise and personal AI accounts
• How to identify AI outputs that require verification before action (factual claims, donor-specific assertions, prospect research findings)
• Where to report concerns about AI behavior, errors, or policy violations
• Regulatory requirements applicable to their role (FERPA for staff handling student data, HIPAA for grateful patient programs, state AI law for constituent-facing decisions)
• The difference between AI that advises and AI that acts, and why agentic AI requires additional governance

Implementation roadmap

This 90-day plan moves an advancement office from no formal AI governance to an operational framework with documented policies, a functioning committee, and a monitoring cadence. Each phase has specific deliverables.

Phase 1: Discovery (weeks 1 through 3)

Objective: Understand what AI your office runs today.

Phase 2: Classification and policy (weeks 4 through 6)

Objective: Classify risk and draft governing documents.

Phase 3: Governance formation (weeks 7 through 9)

Objective: Establish the governance body and approve initial policies.

Phase 4: Training and monitoring (weeks 10 through 12)

Objective: Train staff and establish the monitoring cadence.

After the first 90 days

Ongoing governance follows a regular cadence: quarterly committee reviews, annual audit, and event-driven assessments.

Three patterns that prevent governance programs from sustaining past the first year:

• The committee stops meeting. Scheduling four quarterly meetings at formation (Phase 3) creates accountability. If the committee chair leaves, the charter should name a succession path.
• Platform features ship without review. CRM vendors release AI features in product updates. These updates may enable new capabilities without separate procurement. The quarterly vendor release note review catches this.
• Tier 1 governance is applied to Tier 3 use cases (or the reverse). Applying full committee review to every grammar tool creates friction that pushes staff to use unapproved alternatives. Applying acknowledgment-only governance to predictive models leaves real risk unaddressed.