Write your first AI-use policy in an afternoon

Somebody in your company used an AI chatbot this week. Probably several people did, for emails, summaries, spreadsheets and code. If you have no written rules, each of them is deciding alone what is safe to paste, and most will decide reasonably. A few will not, and they will not know it until a customer asks why their details turned up somewhere they should not be.

A first AI-use policy does not need to be long or perfect. It needs to answer the questions people actually have, in words they will read. This post gives a structure you can fill in during one afternoon and improve later.

Start with what people already do

Before writing a rule, spend twenty minutes finding out what is happening. Ask each team lead three questions: which AI tools do your people use, what for, and what kind of information goes into them. You will get rough answers, and that is fine. The aim is to write a policy about real behaviour rather than an imagined one.

At Kestrel Accounting, a 40-person firm, the answers were a surprise. The partners assumed nobody used AI. In fact the tax team summarised client letters with a chatbot, two juniors used a writing assistant on their phones, and the office manager had connected a meeting note taker to the shared calendar. None of it was malicious. All of it involved client data.

The seven sections

Most first policies work well with seven short sections. Keep each to a few sentences or a short list.

1. Purpose: one or two sentences on why the policy exists. For example: we want people to use AI tools to work faster, without putting clients, colleagues or the company at risk.
2. Who it covers: employees, contractors, interns and anyone else with a company account.
3. Approved tools: the tools people may use for work, or a pointer to where the current list lives. A list kept outside the policy is easier to update.
4. What may and may not go in: the heart of the policy. Name the kinds of information that must never be pasted, and give examples.
5. Checking the output: AI answers can be wrong, so a person stays responsible for anything sent to a client or published.
6. Asking and reporting: who to ask before trying a new tool, and who to tell if something was pasted by mistake.
7. Review: who owns the policy and when it will next be checked.

Writing the data section

This is the section people will remember, so make it concrete. Abstract phrases like sensitive information or confidential material are read differently by everyone. Name the things instead:

• Personal data about customers, patients, students or staff: names with contact details, ID numbers, health details, salaries.
• Passwords, API keys, tokens and anything that unlocks a system.
• Payment card numbers and bank account details.
• Client documents covered by a confidentiality agreement, unless the client has agreed.
• Source code from private repositories, unless the tool is approved for code.
• Unannounced financial results, deals, prices and plans.

Then say what people can do instead. Remove names and replace them with roles. Summarise the problem rather than pasting the document. Use the approved tool that has been checked for that kind of data. A rule that only says no tends to be ignored; a rule that offers a way to get the work done tends to be followed.

Keep the tool list separate

Tools change every month. If the list of approved tools sits inside the policy, every new tool means a new version of the policy and a new round of reading it. Put the list in a register instead and have the policy point to it. The policy states the principle and the register states the facts: which tools are approved, which are restricted to certain data, and which are still being reviewed. A sentence such as: use only the tools marked approved in the AI tool register, for the kinds of information listed against each, is enough.

Make it readable

Write as you would explain it to a new colleague. Short sentences, no legal language unless your adviser insists, and examples drawn from your own work. A policy of two pages that everyone has read is worth more than fifteen pages nobody opened. Ask one person outside IT to read the draft and tell you which sentence they did not understand.

Publish, then ask people to agree

A policy sitting in a shared folder changes nothing. Send it to everyone, ask each person to read it and confirm they agree, and keep a record of who agreed to which version and when. When you change the policy, ask again. That record is what you will show a client or an auditor who asks how you control the use of AI.

In Openn Shield

Openn Shield starts you from two policy templates, Using AI tools at work and Personal data and AI tools, which you edit into your own words. Publishing creates a version that never changes, and each person agrees to that version with a recorded statement and time. The tool register sits alongside, so the policy can point to it. See how policies and agreements work.