A foundation board AI charter you can adopt today.

Most foundation boards approved an AI policy in 2024 or 2025 from a template they never modified. The template was usually written by a law firm or a sector association, presented as a one-pager, voted through in a single meeting, and filed. It satisfied the moment. It did not survive contact with deployment.

The problem with template policies is that they are written to satisfy auditors, not to operate the work. When the executive director sits down to actually apply the policy—to decide whether a program officer can paste a grantee’s narrative into Microsoft 365 Copilot, whether the communications lead can publish an AI-drafted blog post, whether a custom agent built on top of the grants database should be allowed to send email—the template does not answer. The staff fills in the gap with judgment. The judgment is uneven. The board does not know.

Below is a charter built from the work of deploying AI inside real foundations. It is yours to adopt verbatim, modify, or use as a starting point. The charter is offered without restriction; the only thing we ask is that you read the framing first, because the language matters more than the structure.

Template policies fail in deployment because they are written to satisfy auditors, not to operate the work. A real charter has to be four things at once: specific enough to enforce, flexible enough to amend, clear enough for the executive director to apply without calling counsel, and defensible enough for an outside review by funders, regulators, or an investigative reporter.

The structure below is one we have used as a starting point with several foundations. It is deliberately short—a long charter is an unread charter—and deliberately concrete. Adjust it for your context. The variables in brackets are the obvious customizations; the harder customization is the list of permitted and prohibited uses, which has to reflect your actual data classes and your actual operating model.

This charter is written as a starting line, not a finish line. In our experience, three amendments tend to come up first.

The biggest is tightening the prohibited uses when your data classes are particularly sensitive. A healthcare-aligned foundation will add HIPAA-bound language to Section IV and will usually expand Section VIII to define protected health information as a material-incident category. A foundation that holds donor-advised funds will add language about donor confidentiality. A foundation that funds advocacy work in contested jurisdictions will add language about the protection of grantee identity.

The second is loosening the review cadence when your operations move fast. Annual review is the floor; some foundations move to semi-annual review during the first eighteen months after adoption, when the AI environment and the staff’s use of it are both changing quickly.

The third is naming committees that do not yet exist. Most foundations under one hundred million in assets under management do not have an Audit, Risk, or Governance Committee as a separately constituted body. The Executive Committee or the Governance Committee usually absorbs the responsibility. Either is fine; the charter just needs to name the actual body that will do the work. Have your general counsel review before adoption.

A charter is the boundary; it does not do the work. Adoption is the start of the operating posture, not the end of it. To make the charter real, you still need:

• Operational implementation. The seven questions from Before you enable Copilot are the day-one work the charter assumes is in place. Permissions audits, sensitivity labels, conditional access, training, review loops, kill-switch readiness—none of these are charter language. They are charter prerequisites.
• Technical enforcement. Conditional access, Microsoft Purview sensitivity labels, audit logging, and data loss prevention policies do not enforce themselves. Someone has to configure them, monitor them, and tune them. A policy without enforcement is a posture without protection.
• Staff training. The charter is invisible to a staff member who does not know it exists. Adoption needs a communication plan, an onboarding update, and a refresher cadence.
• A relationship with an MIP or equivalent partner. The technical layer, the audit posture, and the quarterly review are interdisciplinary work. The Managed Intelligence Provider model exists to operate it on behalf of organizations that should not be hiring an in-house AI governance team.

The charter is the easy part. The work the charter assumes is in place is the harder part. Both have to exist for either to matter.