Four docs to provide your team with clear AI guidance

When AI policies fail it’s because they don’t hit the right notes: they’re either so cautious that nobody follows them, or so vague that nobody can. Either can discourage widespread AI adoption.

When I helped start an AI working group at Chronicle of Philanthropy, we recognized that they entire concept of AI was hard to grasp for most of the team. In many ways, AI was scary.

To give them well-rounded confidence, we provided four short documents — each with a unique job: why we use AI, what’s allowed, which tools are approved, and where we go next.

The same reminder is included in multiple places: Free-tier tools may train on what you enter, so staff are told not to provide donor, subscriber or reader personal information, unpublished or embargoed editorial content, or sensitive organizational and financial data.

1. An AI philosophy that fits on one page

The first document says why, not what. We organized it around four values the organization already had: integrity, independence, innovation and inclusivity. Each gets one bolded commitment and two or three bullets.

The line that did the most work was this one: “AI is not a shortcut but one of many tools we use to do great work.” It gave staff a test for edge cases the policy didn’t cover. It also reinforced management’s promise that we did not plan to use AI to replace jobs, which provided security.

Two commitments shaped everything after it:

  • Say openly when and how AI is used, with human oversight before anything goes public.
  • Resist the hype. Innovation meant asking critical questions about AI’s impact, not just adopting new tools.

AI is not a shortcut but one of many tools we use to do great work

Note from team AI philosophy

2. An acceptable use policy that names the rules

The second document is where staff look things up. Four decisions made it usable:

  • Disclosure has two tiers. Everyone should feel comfortable to say when their work was AI-assisted. After all, it ends up illustrating to other team members what is possible. Going further, content published in its original AI-generated form is credited publicly.
  • A short list of approved uses. It covers brainstorming, formulas and code, drafting internal communications, transcribing meetings, summarizing research, repurposing your own content and automating repetitive tasks. A list of yeses is easier to follow than a list of nos.
  • Experimentation is encouraged, with a gate. Anything outside the list needs sign-off from technology leadership and the CEO.
  • Hard lines on data. Unpublished or off-the-record material stays in licensed tools with data-sharing turned off; the same goes for confidential or personal (PII) data. AI can’t be used for hiring, promotion or evaluation decisions. Nobody prompts a tool to write “in the style of” copyrighted work.

3. A catalog that keeps the policy alive

The policy points to a shared catalog of approved tools, assembled by the committee. It builds a record of what works and what has been tested.

It lists all the tools to which we have access, their AI features and which ones are approved. Several sections still note that more information is needed — I’d rather publish an honest work in progress than wait for a finished one.

At COP, we are primarily using Claude for Nonprofits. But the team also has access to Copilot (through our Microsoft licenses) and Gemini (through our Google Workspace account). The catalog explicitly states how and when to use the later tools.

The catalog also had a companion: how-to documents for each tool. We included videos, linked to documentation, and described our own use cases.

4. A phased strategy sized to your team

The last piece is a one-page strategy that opens by quoting the philosophy, so the two can’t drift apart. It makes one scoping choice up front: AI is for improving internal workflows and output, not for becoming a feature inside the editorial products. That keeps early decisions small and reversible.

Then it runs in phases:

  • Phase 1: Access, awareness and education. Give every staff member access to approved tools, hold trainings and brown-bag workshops on prompting and responsible use, and document what each available tool can do. Literacy comes before integration.
  • Phase 2: A roadmap. The technology team writes a formal AI roadmap, informed by what Phase 1 turns up. With limited technical resources, the rule is low-lift, high-impact opportunities first and custom integrations later. Staff feedback and use-case submissions are a main input.
  • Ongoing. AI changes fast, and even experts disagree about where it leads. The strategy asks everyone to watch the landscape and share what they find, and sets the posture as “curious, informed, and ready to adapt.”

What I’d copy if I were starting today

  1. Write the values page first and keep it to one page.
  2. Publish the approved uses and make everything else a conversation.
  3. Separate public credit from internal disclosure.
  4. Say plainly which data never goes into a tool.
  5. Build the tool catalog on day one, even if it only has three rows.
  6. Phase the rollout: access and literacy first, integrations only after you know what staff actually use.
  7. Put a review date on the policy. Ours promised regular updates, and that matters more than getting every clause right.

If you’re a small team without a policy, steal this structure. You can have a first draft in a week.