Most companies do not decide whether employees use generative AI. They decide whether employees use it with guidance or without. People paste emails into chatbots, ask them to summarise documents and draft proposals, because it saves time and nobody told them not to. A long policy that nobody reads does not change this. A short one that people can remember does.
This article describes a one-page acceptable-use policy: what belongs on it, how to phrase each part, and an outline you can adapt. It deals with the rules people follow, not with the risks themselves; for those see our piece on shadow AI and the hidden risk in your company. It is a practical outline, not legal advice, and your legal adviser should review the final text.
Why one page
A policy has one job: to change what people do at their desk on an ordinary Tuesday. That requires that they have read it, understood it and can find it when in doubt. A twelve-page document fails the first test. One page, written in plain language, passes all three.
The limit forces useful choices. You cannot list every tool or every case, so you write principles with a few clear examples and point to an owner for everything else. The detail, such as technical settings or supplier terms, belongs in separate documents for the people who need them. If you are building the wider framework, our practical AI governance guide for growing companies shows where this page fits.
1. Purpose and scope, in three sentences
Say who the policy covers (employees, contractors, interns) and what it covers (any generative AI tool that creates text, images, code or audio, including features built into software you already use). Say why it exists: to let people use AI to work faster while protecting customers, colleagues and the company. A positive tone matters. If the page reads as a list of prohibitions, people will quietly stop asking.
2. What you may do
List the uses that are welcome, with examples from your own business. For example:
- Drafting and editing text, such as emails, internal notes and first versions of documents.
- Summarising material you are allowed to share with the tool.
- Brainstorming ideas, outlines and questions.
- Helping with spreadsheets, formulas and code that contain no confidential data.
- Translating and improving the language of text that is not confidential.
Name the approved tools in a short list, with a link to where to get access. Approved usually means the company has checked the supplier's terms on data use and retention, and has set up accounts where the settings are controlled. If you have no approved tool yet, say so and describe the interim rule. People will use whatever is at hand.
3. What you must never put in
This is the most important section and it must be concrete. Abstract words such as "sensitive information" are read and forgotten. Use categories that people recognise at once:
- Personal data of customers, employees or candidates, such as names with contact details, health, salary or performance information.
- Customer and partner confidential material: contracts, price lists, proposals and anything covered by a non-disclosure agreement.
- Credentials and security details: passwords, keys, tokens, internal system diagrams.
- Unpublished business information: financial results, plans for acquisitions, pricing strategy, unreleased products.
- Source code and data that the company does not want to share outside approved tools.
Add the rule of thumb that works well in practice: if you would not paste it into a public forum or send it to a stranger, do not put it into a tool that is not approved for it. For approved tools, state which categories are still excluded. An approved tool may be fine for internal drafts and still not for personal data.
4. You remain responsible for the result
AI output sounds confident, including when it is wrong. State plainly that the person who uses the output owns it. Before anything is sent to a customer, published, signed or used in a decision, a person reads it and checks facts, figures, names and quotations against a reliable source.
Give two or three examples of what this means. Do not send a client a summary you have not read. Do not cite a statistic you cannot trace to a source. Do not use AI alone to make or justify a decision about a person, such as hiring, pay or disciplinary action. Where the output is used with customers, follow the company's rules on informing them; our article on customer notices and human alternatives covers what to say.
5. Be open about use
Ask people to say when AI has materially helped with work that others rely on, at least when the recipient would reasonably want to know, for example in a client deliverable or a report to the board. The aim is not to stigmatise AI help. It is to let reviewers know where to look harder. Also respect other people's rights: do not present generated material as a copy of someone's work, and do not use tools to imitate a real person's voice or image without their permission.
6. New tools and new uses: how to ask
A policy that only says "no" pushes use underground. Give a simple route for yes. Name one owner or a mailbox, promise an answer within a few working days, and keep a public list of tools and uses that were approved. Ask for three things in the request: what the tool is, what data would go in, and what the benefit is. Employees who discover a useful tool then become a source of improvements.
This also covers AI features that appear inside software you already own, and personal accounts on consumer services. State the rule for both. The usual one is that company data does not go into personal accounts.
7. When something goes wrong
Mistakes will happen: someone pastes the wrong document, an answer turns out to be false, a tool behaves oddly. Say who to tell (a named person or a team, with an email address) and how quickly. Then add the sentence that makes the rule work: reporting an honest mistake promptly will not be punished. People hide mistakes when they expect blame, and a hidden mistake is the expensive kind. The owner decides what follows, for example informing a customer or changing a setting. Our guide on incident response and kill switches for AI agents is a good next step for automated tools.
8. Owner, date and review
Close with the name of the policy owner, the date of the current version and the date of the next review. Generative AI changes quickly; plan to review the page every six months, or when a significant tool or supplier changes. A dated page with an owner signals that the rules are alive.
A template outline
- Purpose and scope. Who and what this covers, in three sentences.
- Allowed uses. Five to seven examples and the list of approved tools.
- Never enter. Five categories of data, with examples.
- Your responsibility. Check output before use; no AI-only decisions about people.
- Openness. When to say that AI helped.
- New tools and uses. Who to ask and how long it takes.
- Problems. Who to tell, and the no-blame promise.
- Owner and review. Name, version date, next review.
Rolling it out
Publishing the page is the start. Present it in a short team meeting rather than only by email, and walk through two real examples of acceptable and unacceptable use. Put the link where people work, such as the intranet start page and the onboarding checklist. After a month, ask a few employees what is unclear and fix the wording. Our note on explaining an AI project to employees has more on building trust.
Finally, watch what happens. If many requests for new tools arrive, the approved list is too short. If nobody reports anything, ask whether people are afraid to. The policy is working when employees use AI openly, and when you hear about problems early.
