Set an AI policy people will actually follow.
Most organizations that use AI have one of two policies. The first is a long document of prohibitions, written once by someone careful, filed in a shared drive and never opened again. The second is no policy at all, which in practice means each person on the team has written their own in their head.
Both leave people guessing. A new hire at a town office wants to know whether she can paste a resident's complaint into a chatbot to draft a reply. A project lead at an engineering firm wonders whether a client's drawings can go into a summarizing tool. Neither will find the answer in a twelve-page document, and neither will ask, because asking feels like admitting they already tried it.
Why long policies get ignored.
A policy written to cover every case ends up covering no case clearly. It lists tools by name, and the list is out of date within a season. It forbids things in general language ("do not share sensitive information") without saying what counts as sensitive in this office, with these records. People read the first page, decide it was written for someone else, and carry on as before.
There is also a tone problem. A policy that reads as a list of ways to get in trouble teaches people to hide their AI use. Hidden use is the riskiest kind, because nobody can see what went in, what came out, or whether anyone checked it. A policy that people follow has to make the safe path the easy one to find and take.
Build it around three things.
In our work with teams, the questions people actually ask about AI fall into three groups. What can I put into it? Who will see what comes out of it? And how much should I trust it? A useful policy answers those three, in plain words, with examples from the organization's own work.
Data is the first. Most of the real exposure sits in what people paste in: client files, personnel records, student information, patient notes, anything covered by a contract or a law. The policy should name those categories in the organization's own vocabulary and say which tools, if any, are approved for them. A school district will name different things than a manufacturer, and it should.
Customers, clients, residents and patients come second. If AI helped write something a person outside the building will read, someone inside the building should have read it first. Some organizations also decide when to tell people that AI was involved. That is a values choice as much as a legal one, and it belongs in the policy so that each staff member doesn't have to make it alone.
Judgment is the third, and it is the one most policies skip. AI produces confident text that is sometimes wrong. The policy should say plainly that the person who sends, signs or files the work owns it, whatever tool helped produce it.
A policy that reads as a list of ways to get in trouble teaches people to hide their AI use.
Write it short, and write it for the work.
One page is a good limit. If it runs longer, people will skim it, and the parts they skip will be the parts that matter. Use the names of real systems and real documents: "the case management system," "the bid folder," "anything with a Social Security number." Leave out product names where you can, so the policy doesn't expire every time a vendor changes its lineup. Keep the list of approved tools on a separate page that one person updates.
It also helps to say what is encouraged, alongside what is not. Drafting a first version of a routine letter, summarizing a public report, cleaning up meeting notes from a non-confidential meeting, building a checklist from an existing procedure: if the policy names a few of these, people stop wondering whether any use at all will get them in trouble.
Give it an owner and a review date.
A policy with no owner drifts the same way an unowned automation does. Name one person who answers questions about it and keeps the approved-tool list current. Any reachable person will do, technical or not, as long as they are willing to say "I'll find out" when a question has no answer yet.
Put a review on the calendar, every six months or so, and treat the questions people asked in between as the agenda. If three people asked whether they could use AI on grant applications, the next version should answer that, and the owner should tell those three people when it does.
A one-page starter policy.
Adapt the wording to your organization, replace the bracketed parts, and cut anything that doesn't apply.
Purpose
We use AI tools to save time on routine work and to improve first drafts. This page tells you what is fine, what needs care, and who to ask.
What you can put in
- Public information, your own notes, and internal documents that are not marked confidential can go into any tool on the approved list.
- [Name your sensitive categories: client files, personnel records, student or patient information, financial account details.] These go only into tools marked "approved for sensitive data" on the list, or into none at all.
- Passwords, keys and login details never go into an AI tool.
What goes out
- Anything AI helped write that leaves the organization is read in full by a person before it is sent.
- [State your disclosure rule, for example: we tell clients when AI produced a substantial part of a deliverable.]
Who is responsible
- The person who sends, signs or files the work owns it, including any errors the AI introduced.
- Check facts, figures, names and citations against the source before you rely on them.
Encouraged uses
- First drafts of routine correspondence, summaries of public material, meeting notes from non-confidential meetings, and checklists built from existing procedures.
Questions and updates
- [Name] owns this policy and the approved-tool list. Ask them before you try something you're unsure about. There is no penalty for asking.
- This policy is reviewed every [six months]. Next review: [date].
