An Acceptable Use Policy for Staff Using AI Tools

Staff already use AI tools. Some of that use runs through company accounts and some through personal accounts on work material. A policy that pretends otherwise will be ignored, and a policy that bans every tool will be bypassed in the same way. The purpose of an acceptable use policy here is to make the safe choice clear and to show the reasons, so that a person facing an unfamiliar case can decide well without asking. Short policies with reasons usually do that better than long lists.

Start from data classes

Tool names change quickly, and data classes change slowly. A policy built around named products goes stale within months, while one built around the sensitivity of the data stays useful. Define a small number of classes, commonly public, internal, confidential and restricted or regulated, and say in plain terms what each means. Then state what may enter which kinds of tools. Public material can go into most tools. Internal material can go into tools the organization has reviewed. Confidential and restricted material goes only into tools that meet the specific contractual and technical requirements the policy sets. Boundary cases need a rule too. Aggregated or anonymized data may move down a class, but the rule for doing so should be written and checked by someone who knows the data, since removing names does not always remove identity.

The classes also answer questions the policy did not anticipate. A staff member can ask whether a meeting transcript is internal or confidential, and the answer follows from the definitions rather than from a list of approved products.

Say how each tool was reviewed

An approved list needs a basis. Check each tool against stated criteria: how it handles and stores inputs, how long it keeps them, whether customer inputs are used to train models under the terms in force, what access controls and admin logging it offers, whether it supports single sign-on, and where data is processed. Record the review date and the reviewer. Service terms change, so an approval is a snapshot that needs a scheduled re-check. A tool approved for internal material last year may not meet the same terms today.

Be explicit that the list does not rate quality. It records that a tool met the organization's requirements for a given data class at the time of review. Say also what happens when a tool is withdrawn or its terms change. People who depend on it need a stated fallback and a date by which their work moves.

Define prohibited uses in plain terms

Prohibitions work best when each comes with a reason a reader can apply to a new case. A short list might include the following:

• Do not paste customer records or personal data into a tool that is not approved for that data class.
• Do not put passwords, access tokens or private keys in a prompt, including when debugging.
• Do not let generated text decide something about a person without a human reviewing the basis.
• Do not produce material that imitates a real colleague or customer without their knowledge and a legitimate purpose.
• Do not upload third-party confidential material that an agreement forbids sharing.

Each rule explains itself. A reader who knows that a provider may store or log a key pasted into a prompt can extend that reasoning to a case the list never named. The list also needs a counterpart. A policy that states only prohibitions leaves staff guessing about everything else, and they will fill the gap with habit, so state the common permitted uses in the same plain style.

Handle exceptions in writing

Some legitimate work will not fit the policy. A research team may need a tool that is not on the list, for a defined period and a defined dataset. Give them a route: a short request stating the purpose, the data class, the tool, the duration and the owner who accepts the risk. Approve it for the stated period, log it, and let it expire unless it is renewed. Exceptions granted quietly and never recorded become the real policy, and nobody can see them. A register of exceptions, reviewed each quarter, shows where the policy is too tight and which tools deserve a full review.

Teach the reasons and keep the policy short

A policy of one or two pages is more likely to be read and remembered. Pair each rule with its reason, and include two or three examples on each side, one allowed and one not, drawn from work people actually do. Train with scenarios rather than slides. Ask a team what they used a tool for last week and walk through the policy against it. People who understand why a rule exists apply it correctly to new cases, while people who only memorize a list stop at the first case the list missed. Reasons take more words, so keep each one to a sentence.

Practice by testing the policy

Write three cases a staff member might plausibly face. One might be a customer call transcript used to draft a follow-up email. Another might be an image tool used for a slide that shows an unreleased product. A third might be a coding assistant asked about a stack trace containing an access token. For each case, decide whether the policy answers the question without help. Where it does not, add a rule with a reason or refine a class definition. Then give the case to a colleague who did not write the policy. If they reach a different answer, the wording is the problem, and the policy needs another pass.