Writing a simple AI use policy for your team

Once two or three people on a team start using AI, unofficial rules appear on their own. One person pastes a client email into a public tool. Another refuses to use anything at all. A third drafts a newsletter and, because it sounds polished, sends it with only a quick glance. None of this has to come from bad intent. It comes from the absence of a shared agreement.

A simple use policy is that agreement. It does not have to be long, and it is not a substitute for legal advice. It is a short document, in ordinary language, that tells your people what is encouraged, what is not allowed, and whom to ask when a case is unclear.

What to put in it

You can cover the essentials on one or two pages.

Purpose. Say why the policy exists: to help the team work more efficiently without putting private information, or the organization's voice, at risk.

Approved uses. List the kinds of work that may use AI with review, such as first drafts of public web copy, outlines, internal summaries, or brainstorming. Be concrete enough that a new staff member can tell whether their task belongs on the list.

Prohibited uses. Be just as concrete. Private client, donor, employee, or student information should not be entered into a public tool. Official advice, formal decisions about a person, and anything you would not be willing to stand behind should not be generated and sent without a named human author.

Review. State that a person is responsible for every outward-facing piece of work, including work that began as a machine draft. The tool does not get a byline, and it does not replace a proofread.

Tools. Name the tools the organization is willing to support, or say that new tools need approval before they are used for work. This is less about control than about knowing where information might go.

Questions. Give one name or role as the place to ask. A policy that leaves people to guess will be ignored.

How to write it without getting stuck

Draft it with the people who will use it, not only for them. A short meeting is often enough: walk through a few real tasks, mark each one as allowed, allowed with review, or off limits, and then write those decisions down. Use your own vocabulary. If your organization says "constituents" rather than "customers," use that word.

Keep the tone calm. A policy that sounds like a warning label will train people to hide what they are doing. A policy that sounds like guidance will be used.

A hypothetical example: a small legal office might allow AI for outlining an internal research memo, require a lawyer to review any language that could be shared with a client, and forbid placing confidential case facts into a public model. A small nonprofit might allow help with a public event listing and forbid uploading a donor spreadsheet. The details will differ. The structure can stay the same.

What the policy cannot do

It cannot replace judgment, and it cannot anticipate every case. Leave a sentence that says the policy will be reviewed on a regular schedule — quarterly is a reasonable starting point — and sooner if something goes wrong or a new tool appears. When you update it, tell the team what changed and why.

It also cannot do the underlying legal or ethical work for you. If you handle health information, legal files, children's data, or other sensitive records, talk with the professional advisors you already rely on before you approve a tool. The policy is a working agreement, not a shield.

A good first version

If you are staring at a blank page, write one paragraph for purpose, a short list of approved uses, a short list of prohibited uses, a review rule, and a name to contact. Share it. Try it for a month. Then tighten the language where people actually got confused.

If you would like a second reader for that first draft, we are happy to look at it with you and help you keep it plain.