A company AI usage policy checklist your team will actually follow

Direct answer

A policy people follow fits on one page and answers four questions: which AI tools may I use, what data may I put into them, what must a human check before it goes out, and who do I ask or tell. Anything longer tends not to be read. The checklist below covers seven areas. It is a working template for operational decisions, not legal advice; whether specific rules are needed for your sector, contracts or jurisdiction is a question for your own legal or compliance adviser.

1. Approved tools

List the tools people may use, by name, and what each is for. Keep the list short enough to maintain. Then state the default for everything else, usually "not approved until reviewed", and give people an easy route to ask for a new tool, because a policy without a request route pushes people into using personal accounts quietly.

• Tool name, plan or workspace type, and the purpose it is approved for
• Whether it must be used through a company account and not a personal one
• Where the vendor's data handling terms were reviewed, and by whom
• The named owner for each tool
• How to request a new tool, and the expected response time

2. Data classes

People cannot apply a rule they cannot map to their own material. Define three or four data classes in plain words with examples from your business, and say for each whether it may go into approved tools.

• Public: published website copy, marketing material; generally fine
• Internal: process notes, internal templates, non-sensitive planning; allowed in approved tools only
• Confidential: client data, contracts, pricing agreements, financial detail; allowed only where explicitly stated for that tool
• Restricted: credentials, personal data of special sensitivity, anything you are contractually or legally barred from sharing; never entered

3. Client-confidential rules

Check what your client contracts and NDAs already say about third-party tools and subcontractors before writing this section. Then decide, per client type, whether their material may be used in AI tools at all, and if so which ones. Where a client has asked not to have their data processed by AI, record that in the client file so that a junior team member does not have to remember it. Also decide whether and how you tell clients that AI was involved in preparing work for them; the right answer depends on your contracts and your relationship, and should be a deliberate decision, not an accident.

4. Human review

State which outputs need a human check before they leave the company and who does it. Anything that reaches a client, is published, makes a commitment, contains numbers, or gives advice needs a named reviewer. Say what the reviewer is checking: facts and figures, tone, names, quoted sources, and whether the output says something the company would not stand behind. Make it explicit that the person who sends it owns it; "the AI wrote it" is not a defence internally or with a client. Also say what should never be fully automated without review, such as replies that commit to prices or dates.

5. Accounts and administration

Decide who administers each tool: creates and removes users, sets sharing and retention options available on your plan, and reviews usage. Company accounts should use company sign-in wherever the tool supports it, so that access ends when employment does. Note the settings you have chosen for training on your data and history retention, and record where you checked them, since these depend on the vendor and the plan and can change. Keep a simple register of tools, owners, plans and review dates. Reviewing it quarterly is realistic; reviewing it monthly usually is not.

6. Incidents and offboarding

Say what counts as an incident, for example confidential data pasted into an unapproved tool, an AI-generated error reaching a client, or a shared account compromised, and who to tell and how fast. Make reporting safe: if people fear punishment for a mistake, they will hide it. Then cover offboarding. When someone leaves, their access to AI tools is removed, and any chats, projects or custom assistants they built that hold company knowledge are transferred to an owner. This mirrors what you would do for a CRM; see CRM handover when a salesperson leaves for the same logic applied to sales records.

7. Rollout and training

A policy in a shared drive that nobody has been walked through is decoration. Announce it in a short session, show the data-class examples with real tasks from your own work, and give a one-page reference people can find in under a minute. Ask each person to confirm they have read it, and revisit it after the first few weeks with questions from actual use. Update it when tools or client requirements change. For adoption beyond the policy, see AI team training and adoption, and for what usually goes wrong, AI implementation mistakes.

Turning the checklist into a working setup

Writing the page is the easy half; the harder half is making the tools match it: company accounts, roles, sharing settings and a shared set of instructions. LATYNEX can do this as part of AI Governance and Usage Policy work, and the fixed-scope AI Team Setup package on AI Implementation for Business covers roles, usage rules and onboarding for one workspace. We do not offer legal or compliance advice and we do not claim certifications. If you want a quick view of where you stand first, the free AI implementation readiness assessment is a starting point.