A Volunteer AI Policy You Can Enforce
Most nonprofit AI policies were written for employees and quietly assume an employment relationship: onboarding, managed devices, a supervisor, and a disciplinary ladder. Volunteers have none of those, which is why the policy that governs your staff usually stops working the moment an unpaid person opens a chatbot. This is what to do instead.
A retired accountant volunteers on your finance committee and uses an AI assistant to help interpret a set of statements. A pro bono designer builds your gala invitation with a generative tool. A board member pastes the draft strategic plan into a chatbot to get a second opinion before the meeting. A weekend volunteer coordinating a food distribution asks an assistant to write the sign-up instructions in Spanish. None of these people are employees, none went through your staff onboarding, and in most organizations none of them have ever seen your AI policy.
This gap is common and it is structural rather than negligent. Organizations that have written an AI policy at all typically wrote it during a staff conversation, distributed it through a staff channel, and enforced it through a supervisor relationship. Every one of those mechanisms assumes employment. Volunteers arrive through a different door, use their own equipment and accounts, may serve for one afternoon or twenty years, and cannot be managed with the tools that make a staff policy work.
The exposure is not theoretical. In many nonprofits, volunteers handle more sensitive information than junior staff do. Board members see personnel matters, legal exposure, and donor capacity ratings. Direct-service volunteers meet clients face to face and hear things staff never hear. Pro bono professionals receive whole datasets so they can do the work you asked them to do. If your AI rules do not reach these people, they do not reach the material that matters most.
This article covers why staff policies fail when applied to volunteers, how to segment a volunteer base by what it can actually expose, the five things a volunteer policy has to say, how to enforce rules when you have no employment leverage at all, and the specific problems posed by pro bono professionals and board members. It ends with the structure of a one-page document a volunteer will read.
Why the Staff Policy Does Not Transfer
The instinct when someone raises this issue is to email the existing policy to the volunteer list and consider the matter handled. It is worth understanding why that does not work, because the reasons determine what the replacement has to look like.
Staff policies rest on infrastructure that does not exist for volunteers. There is no managed device, so you cannot control which tools are installed or which accounts are used. There is often no organizational email address, so the volunteer is working in a personal account you have no visibility into. There is no annual review, no performance conversation, and no progressive discipline, so the consequences section of a staff policy describes a process that cannot occur. Many volunteers have no single supervisor at all, particularly in episodic and event-based roles.
Staff policies also assume a reader with organizational context. They reference systems by internal name, cite other policies, use terms like PII and data classification, and run to several pages because an employee is being paid for the time it takes to read them. A volunteer giving three hours on a Saturday will not read six pages of policy language, and a policy that is not read is not a control. It is documentation of an intention.
The final difference is the most awkward one. Staff policies work partly because employment creates leverage, and volunteers can leave at no cost. That is not a reason to abandon rules; it is a reason to write rules that a reasonable person will follow because they understand them and agree with them, rather than rules that depend on consequences you cannot impose. The organizations that get this right treat the volunteer policy as an act of persuasion backed by access control, not as a legal instrument.
If your organization has not yet written any AI policy at all, start with the general approach rather than the volunteer edge case. The guides to creating an AI acceptable use policy and building a nonprofit AI policy in a single day cover the foundation this piece builds on, and the discussion of why most nonprofits still have no AI policy explains why the gap persists.
What Staff Policies Assume
Every one of these is missing for volunteers
- A managed device and an organizational account
- A named supervisor and a review cycle
- A disciplinary process with real consequences
- Paid time in which to read a long document
- Shared vocabulary and organizational context
What You Actually Control
The levers that do exist
- What information you hand a volunteer in the first place
- System access, permissions, and export rights
- A signed acknowledgment as a condition of the role
- Whether the volunteer continues in that role
- Whether staff review the work before it is used
Segment by Exposure, Not by Hours
Most volunteer programs classify people by commitment level: regular, episodic, seasonal. For AI policy purposes that classification is close to useless, because the risk has nothing to do with how often someone shows up. A volunteer who serves once a year on a grant review panel may see more sensitive material in that afternoon than a weekly shelf-stocker sees in a decade.
The useful question is what the volunteer can expose. Sort your roles by that and the policy almost writes itself, because most volunteers turn out to need very little and a small group turns out to need real attention. Trying to write one rule that covers both the gala check-in table and the finance committee produces a document that is simultaneously too heavy for one and too light for the other.
At the low end are volunteers who handle no confidential information: event setup, facilities, food sorting, trail maintenance, ticket scanning. These people need a sentence, not a policy, and requiring more of them wastes their goodwill and your administrative capacity. At the high end are board members, finance and audit committee volunteers, pro bono professionals with dataset access, grant reviewers, and any volunteer in direct client contact. This group needs the same standard staff meet, and in some cases a stricter one, because they are working outside your systems.
The middle band is where most organizations get caught. Communications and marketing volunteers, database helpers, translators, tutors, and mentors all handle information that is not obviously confidential but becomes so in aggregate or in context. A volunteer writing thank-you notes is looking at a donor list. A tutor knows which children are struggling and why. A translator handling intake forms is reading everything on them. These roles need a real rule and rarely have one.
Three Tiers That Actually Map to Risk
Sort roles by what they can expose, then write to the tier
- Tier one, no confidential access: Event support, facilities, sorting, setup. One sentence in the volunteer briefing is sufficient.
- Tier two, incidental access: Communications, tutoring, mentoring, translation, data entry. Needs the one-page policy and a signature.
- Tier three, substantial access: Board, finance and audit committees, grant reviewers, pro bono professionals, direct client contact. Needs the staff standard plus a conversation.
The Five Things the Policy Has to Say
A volunteer AI policy that runs longer than a page will not be read, so everything in it has to earn its place. Five things genuinely need to be there, and almost everything else that appears in staff policies can be cut.
The first is the hard line on information, stated concretely. Abstract categories like confidential information mean nothing to someone who has never been trained on your data classification scheme, so name the actual things: client names and any detail that could identify a client, donor giving amounts and capacity notes, staff personnel matters, anything from a closed board session, and anything a person told you in confidence. Say plainly that none of it goes into an AI tool, and that this holds regardless of whether the tool promises privacy.
The second is a rule about accounts, which is where volunteer policy diverges most sharply from staff policy. Volunteers will use their own tools; you cannot prevent it and pretending otherwise produces a policy everyone ignores. The workable rule is that personal accounts are acceptable for work involving no confidential information and unacceptable for anything else, and that if a role requires AI on sensitive material, the organization provides an account with appropriate settings. This is more honest than a prohibition nobody will follow.
The third is a review requirement. Any AI-assisted work a volunteer produces for external use, whether that is a social post, a donor letter, a translated flyer, or a grant section, is reviewed by a named staff member before it goes out. This single provision catches most of what actually goes wrong, because the failure mode in volunteer AI use is rarely a data breach. It is an inaccurate claim, a hallucinated statistic, an off-voice message, or a translation that says something the organization did not mean.
The fourth is disclosure, and it should be lightweight. Volunteers tell the staff contact when AI was used substantially in producing something, not as a confession but so the reviewer knows what kind of check to run. A draft written with AI assistance needs its facts verified more carefully than one written from a volunteer's own knowledge, and the reviewer can only calibrate if they know. The broader question of where labeling belongs is covered in the piece on where nonprofits should disclose AI use.
The fifth is a named person to ask. Most volunteer AI problems are not defiance; they are a reasonable person guessing at an edge case the policy did not anticipate. A name and an email address, with an explicit statement that asking is always welcome and never held against anyone, converts those guesses into questions. Organizations consistently underrate this line and it may be the highest-value sentence in the document.
The One-Page Structure
Six short blocks a volunteer will actually read
Written in plain language, fitting on one side of one page, signed at intake.
- Why this exists: Two sentences on protecting the people you serve, not on liability
- Never goes in a tool: A concrete list, named specifically, no abstract categories
- Which account: Personal accounts fine for non-sensitive work, organizational account otherwise
- Staff review: Anything going outside the organization is checked by a named person
- Tell us: Mention substantial AI use so the reviewer knows what to verify
- Ask anytime: A real name and email, with asking explicitly encouraged
Enforcement When You Have No Leverage
The honest starting point is that you cannot discipline a volunteer in any meaningful sense. There is no pay to withhold, no promotion to deny, and no performance plan to impose. What you have instead is control over access, control over assignment, and the ability to end the relationship, and a policy built around those three things is enforceable in a way that a policy built around consequences is not.
Access control is by far the strongest lever and the most underused. A volunteer who is never given the full donor export cannot paste the full donor export into a chatbot. Read-only permissions, filtered views, redacted records, and task-scoped access do more for your risk position than any document, and they work whether or not the volunteer ever reads the policy. Before writing rules about what people may do with data, look hard at whether they need the data at all.
Assignment design is the second lever. If a task genuinely requires handling sensitive material, ask whether it should be a volunteer task. Some should not be, and recognizing that is a legitimate policy decision rather than a failure of trust. For the tasks that remain, structuring the work so the volunteer receives only the portion they need, and returns work into a staff review step, contains most of the risk without any monitoring at all.
The acknowledgment signature matters more than it looks. Not because it creates legal exposure for the volunteer, which is largely illusory, but because signing something changes how people treat it. A volunteer who has signed a one-page document at intake has read it, which is the entire objective, and has been given a clear signal that the organization takes this seriously. Fold it into the existing intake paperwork rather than sending it separately, since a separate email will be ignored.
Finally, be realistic about the last resort. Removing a long-serving volunteer from a role is genuinely difficult, socially costly, and sometimes politically fraught when the person is well connected or a donor. That difficulty is exactly why the earlier levers matter, and it is also why the policy should focus on preventing the situation rather than describing what happens after it. Where the tools can genuinely help volunteer programs run better, the guide to streamlining volunteer onboarding and training covers the operational side, and organizations running entirely without paid staff will find the constraints discussed in the guide to all-volunteer nonprofits.
Controls That Work Without Discipline
Ordered by effectiveness, not by effort
- Give the minimum data the task requires, not the full record
- Use read-only and filtered views rather than export rights
- Route all outbound work through a named staff reviewer
- Fold the acknowledgment into existing intake paperwork
- Reassign genuinely sensitive tasks to staff where warranted
The Pro Bono Professional Problem
Skilled volunteers are the hardest case, and the difficulty is not technical. A marketing consultant donating twenty hours, an attorney reviewing a contract, a data analyst cleaning your database, or an agency producing a campaign at no charge all bring their own professional toolkit, and that toolkit now includes AI as a matter of course. Asking them to work differently for you than they work for paying clients is an awkward request to make of someone doing you a favor.
It is also frequently the right request, because pro bono engagements involve the deepest data access in the entire volunteer program. An analyst cleaning your donor database has everything. An attorney reviewing an employment matter has personnel details. A consultant building a communications strategy may receive board materials, financials, and program data in a single handoff. The exposure is closer to a vendor relationship than a volunteer one, which points toward the answer.
Treat skilled volunteers under the same framework you would apply to a paid contractor, and say so at the outset. Scope the engagement in writing, specify what data is being shared and for what purpose, state your AI expectations directly, and ask what tools they intend to use. Most professionals respond well to this because it is a normal client conversation rather than a suspicion, and the ones who react badly to being asked what tools they use have told you something worth knowing. The related considerations around vendor and contractor terms are covered in the guidance on AI policy templates by nonprofit sector.
One specific provision is worth including in every skilled-volunteer arrangement: a statement about what happens to your data after the engagement ends. Pro bono relationships tend to conclude informally, with nobody ever asking the consultant to delete the files. Putting a deletion expectation in the initial scope is easy at the beginning and awkward eighteen months later.
Your Board Is a Volunteer Group
The group most likely to be excluded from a volunteer AI policy is the group with the greatest access to sensitive material. Board members are volunteers in every formal sense, and they are almost never covered by the volunteer handbook, rarely covered by staff policy, and typically the last people anyone is willing to hand a compliance document to.
What they handle makes the omission serious. Board packets contain financial detail ahead of public release, executive compensation discussions, litigation and risk matters, major donor capacity assessments, and the minutes of closed sessions. A director who pastes a board packet into a personal chatbot to get a summary before a meeting has moved all of that outside the organization, usually with no idea that this constitutes a decision at all.
The framing that works with boards is governance rather than compliance. Directors are accustomed to duty of care and confidentiality obligations, and AI use fits naturally into that existing vocabulary in a way that an acceptable use policy does not. Fifteen minutes at a governance committee meeting, resulting in a short addition to the annual conflict of interest and confidentiality acknowledgment that directors already sign, accomplishes more than any handbook distribution would.
Executive session material deserves a specific carve-out. Anything discussed in closed session, and any document prepared for it, should be explicitly off limits to AI tools with no exceptions and no reliance on tool settings. It is the clearest bright line available in the entire policy, it is easy for directors to remember, and it protects the category where a leak would do the most damage. Keeping the broader policy current as tools change is covered in the guide to updating your AI policy.
Conclusion
Volunteers are using AI in your organization right now, and in most nonprofits nobody has told them anything about it. The reason is not carelessness. It is that AI policies were written inside a staff conversation, using mechanisms that only exist within employment, and the volunteer base was never in scope.
The replacement is smaller than the thing it replaces. Sort volunteer roles by what they can expose rather than by hours served, write a single page for the middle tier, hold the top tier to the staff standard, and give the lowest tier a sentence. Five provisions carry the weight: a concrete list of what never goes in a tool, a workable rule about accounts, mandatory staff review of anything going outside, lightweight disclosure so the reviewer knows what to check, and a named person who is genuinely happy to be asked.
Enforcement comes from design rather than discipline. Access control, task scoping, and a review step contain most of the risk without depending on leverage you do not have. Skilled volunteers should be handled like contractors, with scope and data expectations agreed at the start and a deletion expectation attached. Board members need the same rules delivered as governance, with executive session material placed firmly out of bounds.
None of this requires a large project. It requires one afternoon, one page, and the willingness to have a short conversation with people who are already giving you their time and would generally prefer to be told what the rules are than to guess.
Write Rules People Will Actually Follow
We help nonprofits set AI boundaries that reach everyone who touches the mission, including the people who are not on the payroll.